Insights - How to Structure a Great Project Proposal.
How to Structure a Great Project Proposal.
Writing project proposals (or project quotations) efficiently and effectively is a critical part of the sales process in every business. The key challenge in the creation of such proposals is capturing the commercial engagement process that took place between two parties (the author of the proposal and the receiver) on a single document that both parties can agree on. The reason this is challenging is that - due to the verbal and non-committal communication leading to the project proposal stage - both parties may have differing perceptions of what has been agreed. In this article, we detail a proven structure that enables to write great project proposals i.e. proposals that establish mutual understanding on why the parties engage (purpose), transparency on what both parties aim to achieve (integrity), and clarity on how both parties' success will be measured and rewarded (trust).
Let us look into each section of a project proposal in more detail. In the following we will use the word "you" to address the author, the verbs "must/shall/should" to indicate mandatory elements to include, and the verbs "can/may" to indicate optional elements whose inclusion is at the author's discretion. As a rule of thumb, every section below shall start on a new page within the proposal document format used.
COVER
This is the first impression for the receiver of the proposal. You should include the logo & name of your company, the jointly agreed name of the project, the receiver's name, as well as references to any existing commercial agreement this project is connected to. You may also include an image that visually describes the outcome of the project for those who will benefit from it: your customers and/or your customers' customers. Remember that your project proposal may be shared with others in the receiver's company.
INDEX
A frequently missed opportunity, the index is an important indication of the quality of the proposal. A quick look will let the receiver assess if your proposal contains the information they need to be able to get approval for it. This is critical! If your proposal does not help the receiver "manage their behind-the-scenes, non-solution-related change management issues", your project proposal will not be accepted. Therefore we recommend that if you have been asked for product specifications, you must both include the specifications as an appendix as well as add a visible "Product Specifications" item in the Index.
INTRODUCTION
This is the place where you document the common understanding of the "why" you engage with the receiver, and this project is taking place. You shall list the relevant objectives the receiver has shared with you in the engagement process, using the receiver's own words and terminology. You must then declare which of those objectives your proposal addresses. Be clear whether you fully deliver, or partially contribute, towards an objective.
You may list in this section your credentials and references, starting with those which are relevant to the delivery of the objectives the proposal addresses. Resist however the temptation to include marketing messages (in this and any subsequent sections). The project proposal should be drafted after a common understanding has been achieved. You will know if a proposal was sent too early by the number of times you may have to update it.
ASSUMPTIONS
It is only in rare cases that both parties (you - the author - and the receiver) will have full control over the project execution. The Assumptions section is the place to document all areas that are relevant to the project execution but cannot be predicted by either party at the time the proposal is created. You must indicate the impact of the assumptions being proven wrong (Risk Assessment), and also the (Change Management) process both parties will follow if a Risk materialises. As a rule of thumb:
- For small projects, the risk assessment can be as simple as indicating "timeline impact", "price impact", etc.
- For large/complex projects you may need, or be required, to create a dedicated document evaluating each risk on severity, probability, and impact, as well as identifying possible mitigation actions.
BASELINE
Equally rare, is that you deliver a project with no historical data or foundations (a baseline) to use as a starting point.
- If no historical data or foundations exist, or the relevant information is not (made) available to you while authoring the proposal, you must document this fact in this section, and you must also add one or more assumptions to define the lack of predictability caused by the lack of historical information. For example, if you are asked to integrate functionality that is yet to be released, you must add a description of it in the baseline, as well as a series of assumptions e.g. that pricing of the integration will be defined as soon as the functionality is released, adequate documentation is available, etc.
- If historical data exists and you have (been given) access to them, you must detail them here.
STATEMENT OF WORK
This is the core of every project proposal. You must list everything you are actually going to do and deliver. As a rule of thumb, think of tasks whose delivery can be assigned to a person (small projects) or team (large/complex projects). As a best practice, you may add unique labels to identify each deliverable you include here, e.g. SOW-1, SOW-2, ... SOW-n.
DEPENDENCIES
Few projects can be delivered in isolation, and it is very likely that you will need the receiver to perform certain activities upfront or in parallel to you, to enable you to deliver the items listed in the Statement of Work. You must list these dependencies on the receiver here. You may use the labels you assigned earlier to connect the dependencies on the receiver to the delivery of the items in the Statement of Work e.g. DEP-1, DEP-2, ... DEP-n.
PROJECT PLAN
The next part of your proposal is related to planning the execution of the project, using the Assumptions, the Baseline, what you will do (Statement of Work), and what the receiver will do (Dependencies) to enable you to deliver. You must list the resources (people, processes, tools), the calendar time and the actual effort required to deliver the Scope of Work. It is a best practice that the Dependencies on the receiver are part of, and managed in, the same Project Plan so that both you and the receiver acknowledge and assume joint ownership of successful delivery.
ACCEPTANCE
This section must contain the Acceptance Criteria, defined as a list of actions you are going to perform to demonstrate to the receiver that you have delivered each of the items described in the Statement of Work.
- For small projects, a simple list or table will be sufficient, together with an entry in the Project Plan. You may use the labels mentioned previously to connect actions to items in the Statement of Work e.g. ACC-1, ACC-2, ...ACC-n.
- For large/complex projects you may need to attach an Acceptance Plan, defined as an additional project plan that details how acceptance will be performed.
PRICE AND PAYMENT
The Project Price is defined as the value of delivering against the receiver's objectives. Delivery is accomplished by performing the items in the Statement of Work, under the Assumptions, Baseline, and timely delivery of the Dependencies by the receiver. The price shall be detailed in this section of your proposal. In addition, you must detail when and how you want to receive the price (Payments Terms). The definition of "value", and thus price, varies depending on the engagement model e.g. consultants may be paid with a sum equal to the number of days of effort times a day rate, whereas startup advisors may be paid with a percentage of a company's shares. Similarly, payment terms may be linked to milestones (acceptance of items, or groups of items, in the Statement of Work) or achievement of business benefits e.g. payment of x only if revenue exceeds y.
REFERENCES AND APPENDIX
The Project Proposal cannot possibly replicate/include all relevant information in written form. If you need to refer to documents owned and provided to you by the receiver, you must ensure they have a unique name so that they can be referenced unambiguously. As a best practice, you may use numbered references, so that you can refer to them easily. Your own information - in particular, if you have been required to do so - can be included in full in an Appendix or attached to the Project Proposal when the used document format allows doing so.
IN SUMMARY
In this article, we detailed a proven structure that enables to create great project proposals. Adopting this structure enables to establish mutual understanding on why the parties engage (purpose), transparency on what both parties aim to achieve (integrity), and clarity on how both parties' success will be measured and rewarded (trust).
CREDITS & REFERENCES
For the avoidance of doubt, Neos Chronos is not affiliated with and has no financial interest in any of the companies mentioned in this article. All names and trademarks mentioned herein are the property of their respective owners. Please observe the Neos Chronos Terms of Use.
- Wikipedia: Baseline, Dependencies, Project Plan, Pricing
INTRIGUED?
For more information on how our advisory services can help you and your company create great project proposals, please contact us to arrange an introductory meeting or
Book a Discovery Session now!
Get to know us. Put us to the test.