10 Steps to Writing Winning Project Proposals
By Cory "Bubba" Cunningham
What is a project?
A project is an action performed by a business that is outside the normal daily operations of the organization. Projects could be as small as installing a piece of software on a server or as large as changing product lines to enter a new market of business. All projects require resources. Resources can be people, money, equipment, or some other asset.
What is a project proposal?
A project proposal is a document that outlines how resources could be used to either profit the organization, or reduce the amount of cost or future risk required to perform current business. In some cases, the organization has plenty of resources, so the proposal only needs to provide solid evidence that the project will generate some type of profit. In most cases, the organization has fewer resources than what is being requested to complete all of the proposed projects. In these cases, project proposals have to compete with one another to get approved.
What is so difficult about writing a project proposal?
Project proposals are not as simple as stating a need and a suggested solution. First, not everyone perceives the needs of an organization the same way. The people who write the checks feel differently than the people doing the labor. You have to convince both types of people in one proposal.
Second, your idea of a good solution may differ than another stakeholder of the project. Project proposals often never get submitted because the people writing them don’t agree on how the project to work.
Third, everything you think you know needs to be proven on paper. Just because you know it is right, doesn’t mean you can prove it. It is kind of like having to show your work in math class; anyone can guess the right answer.
Finally, the number one reason that most project proposals are never finished is because the proposal writers didn’t know how to start them.
In this document I intend to walk you through the steps from start to finish of writing a complete project proposal. Follow along my 10 steps for writing project proposals, and you will see how to tackle all the issues I just outlined.
Contents (Quick links)
Depending on your organization, you may or may not already have a standard project proposal template. If your organization has a template, and you are required to use it in its entirety, then skip to step 2. If you have some leeway in your organizations project proposal template, or you have to create one from scratch, then your first step is choosing the sections that you want to include in your proposal.
Project proposals have a few standard parts. The first is the project proposal cover page. This is the first page of a project proposal, and it contains the high level information about the project. Often, it is the only page seen during initial reviews.
Standard sections of a project proposal cover page:
* Name of the project
* Type of project
* List of stakeholders involved in the project
* Problem Statement & Solution Statement or Opportunity Statement & Action Statement
The next area of a project proposal is the body. Proposal body sections can vary dramatically between organizations, and even within an organization depending on the type of project proposal.
General sections of proposal bodies could include:
* Deliverables
* Scope statement
* Objectives
* Action plan
* Historical information
* External or additional information
This list is neither exhaustive nor mandatory. Often, body sections can seem redundant, but as the process for extracting information from the proposal team they may prove useful for categorizing raw information.
The third area that most project proposals have is the evaluation criteria. This area if the proposal is designed to quantify potential positives and negatives of the project. Often, these sections are mandated by the organization in order to standardize how projects are evaluated.
Standard sections of an evaluation page:
* Costs – One-time and on-going
* Benefits or expected profit
* Risks
* Risk mitigation plan and/or exit plan
* Strategic alignment
See Step 8 for more details on the area.
Projects fall into one of two categories; they are either a solution to a problem, or they are a means to capitalize on an opportunity. The type of project being proposed will dictate how to phrase the wording in the body of the project.
Projects that fix problems start with a “Problem Statement” followed by a “Solution Statement”. Projects that are going after additional gain start with an “Opportunity Statement” followed by an “Action Statement”.
Problem and Opportunity Statements
The problem statement should be short and to the point. The rule of thumb is to keep the problem statement to 30 words or less. Those 30 words need to be able to summarize the problem and nothing more. Think of the problem statement as the first paragraph of a news article. The problem statement needs to contain the most important facts about the situation without getting bogged down with extra information that could distract the audience from the core issue.
The solution statement can be longer than the problem statement, but it should stay under 50 words. Like the problem statement, the solution statement needs to be to point. The Solution statement is the sales-pitch of a project. The solution needs to explain in a single paragraph what is being proposed to solve the problem.
The problem and solution statements together will create the equivalent of a business mission statement.
Example of a good problem and solution statement:
Problem Statement:
The company’s ERP software will be unsupported by the vendor in 6 months, leaving the company exposed to possible system outages that would disrupt daily business.
Solution Statement:
Implement an upgrade to the current supported version of the ERP software in each department one at a time inside a three month window using upgrade plan provided by the vendor.
In opportunity projects, the opportunity statement and action statement follow the same rules as the problem statement and solution statement. In some proposal templates, the headings are mixed, for example: Problem/Opportunity Statement and Solution/Action Statement.
The main difference between the two types is the wording and how each type creates a sense of urgency. Problem project proposals are worded so the audience feels an urgent need to avoid a risk, while opportunity project proposals are worded so the audience feels an urgent need to take action to capitalize on a potential benefit.
In most cases the type of project will seem obvious from the get go. However, there are situations where a project proposal can be pitched either as a problem or an opportunity. Depending on the business environment and the intended audience of the proposal, one type may be perceived in a more favorable light.
Using the example of the problem and solution statement above, here is an example of the same proposal worded as an opportunity and action statement:
Opportunity Statement:
A new version of the ERP software with features that will save the company a considerable amount of resources is available within our current support window.
Action Statement:
Implement an upgrade to the current version of the ERP software with the new features in each department one at a time inside a three month window using upgrade plan provided by the vendor.
One thing to keep in mind when writing the opening statements is that until the proposal is finalized these statements are editable. They don’t have to be perfect before the body of the proposal can start. Often times, the solution or action statement can’t be completed until the end of the proposal writing process. For example, the solution in the examples above may be to switch vendors, but that vendor may not be identified until later on in the process. Also, as the proposal writing process proceeds a better solution may become apparent to the proposal team.
Step 3: Prepopulate the form with what you already know
Project proposals are rarely a solo activity. Chances are you have a small group of stake holders who are eager to get started on this project and are just waiting to have the proposal completed and signed off so they can start doing things. Your job is to get what is in their heads down on paper so they can explain to the organization just how wonderful their plan is. The problem is, when you sit down for the first time with the group no one knows what to put down except, “It’s a really good idea”.
The key to solving this problem is to think of the actual document of the project proposal as a workbook that can be edited and revised many times before it is submitted. It is also a tool for you as the proposal writer to generate ideas from other members of your team.
Before you meet with your proposal team for the first time, write in as much as you know in all sections of the project plan. It is easier to edit than it is to create, so what you are trying to do is put in as much raw data that the team can use to stimulate their own ideas.
Tip: Don’t worry about being accurate when you are prepopulating information. Let the team correct your work. If you know a piece of information is not correct when you enter it, highlight it in the document and use it as a discussion tool.
The goal of this process is to have raw information that the team can work with and stimulate ideas, rather than presenting them with a blank page which can cause group writers’ block. Also, you might not meet with your team in person, so sending a document with information gives them an example of what you are looking to have them provide.
After you have put in as much information as you can think of in all the sections of the project proposal you may find that some of the sections are either still blank, or very light. The next step is to write in specific questions to ask the team. Remember, at this stage of the proposal the document is a workbook. These questions you add will be replaced by the answers as statements in the proposal.
The question format is also useful if the proposal team is not meeting face-to-face. You can send the document to each team member requesting they answer the questions individually. The result can be multiple answers to the same question, which would then be listed as multiple statements within the sections.
Example of questions inside a proposal section:
Risks:
* What will happen if the software doesn’t work the way it was promised?
* Which departments will be without service?
* How many customers do those departments support?
* How long will it take to roll back to the old version? Can we roll back?
* What contact obligations does the vendor have for supporting the company? What if they don’t honor them?
* What will happen if we DON’T upgrade?
Example of multiple possible answers:
Risks:
* What will happen if the software doesn’t work the way it was promised?
It would cost a lot of money for the accounting department – Bob
Our customer web portal won’t work with the new Internet browsers – Julie
We won’t be able to integrate with the Federal Government’s new software - Rick
Just like Step 3, the goal of this activity is to stimulate ideas.
If you haven’t already sent the project proposal with your prepopulated information and questions to the team, then the first time you meet with the proposal team it will be very important to explain the purpose of using the project proposal as a workbook. Start by reading through the whole proposal as a group so everyone can get the big picture.
Next, go back through the document and discuss the sections and document everything not matter how insignificant it may sound. Insignificant utterances have a tendency to turn into significant statements after they are discussed.
Tip 1: Use a projector and type in the information as it is being discussed. This will allow for editing on the spot by the team, and it will build confidence from the team that you heard what they said.
Tip 2: If you are using a projector, DON’T provide printouts. By having to watch what you are doing on screen, the team is forced to stay focused on the topic currently being discussed.
The goal of this activity is to extract as much information as possible from the team. It is not important at this point to have the ideas be complete or fully edited. It is also okay to have the same idea expressed in multiple formats.
Before moving onto the next step, take a break. Give the proposal team copies of what you have so far and let them digest it. Have them look at it cold in a few days. Ideas that seemed really good a few days ago might not be so great today. Inversely, ideas that wouldn’t come to the surface when you met face-to-face may be popping up now. Another meeting might be necessary, or individually submitted changes might be sufficient. Keep adding information until you either run out of time, or the team stops sending changes.
By this step there should be a plethora of information haphazardly packed into each section of the project proposal. It is time to start editing.
Start with the low hanging fruit, which is duplicate information. Go through each section individually at first and combine similar thoughts, and remove anything that is repetitive. Then look at the entire document for duplicate information across multiple sections. Sometimes having duplicate information, phrased differently, in multiple sections is okay.
Tip: Don’t delete text from the document in the first few passes. Use the edit tool of the word processor software, or simply use the strikeout text tool. Not only does this allow you to recover mistakes later, it is also handy to show the team what you removed.
Next, complete any incomplete statements in each of the sections. It may be necessary to truncate multiple fragment statements into a bullet point list. You can also expand on ideas. Don’t be afraid to contact your team for more clarification.
Finally, organize the statements within each section into a logical order. You can insert connector information if necessary. If the information is in list format, pick a logical order. For example, “Risks” would be listed in order by potential severity starting with the greatest first. And “Deliverables” should always be listed in the expected order of completion.
As mentioned at the end of Step 2, the solution, or action, proposed at the beginning of your proposal document may need to be reevaluated depending on any discoveries made during the process of building the project proposal. For example, the risk of the proposed solution may turn out to be greater than that of an alternate solution. Or an alternate solution was discovered that had greater benefits. And in some cases the necessity of the project may be determined as insufficient to proceed.
Tip: Don’t be afraid to terminate a dead proposal. If the information gathered in the writing process contradicts the fundamental purpose, don’t try to bend the truth to make it fit. One of the key benefits of good project proposal is to force the requestors to prove their concept on paper. If they can’t prove it to themselves, then the project proposal doesn’t have a chance when it gets critiqued and evaluated by the funding body.
The other part of this step is to make sure that all the sections fit together as a whole unit. After working with the information over and over you may be reading messages into the material more than is actually there. If you can, this is the time to bring in an outside party to test your project proposal.
Here is a few question that you can ask a third-party to answer when reviewing the proposal:
* Does the information in each of the sections flow from one section to the next without gaps?
* Do any of the sections seem to be irrelevant or contradict the rest of the body?
* Do any of the sections contradict the solution or action statement?
* Is the reader left with any unanswered questions?
The findings from these questions should give you a good idea of where you need to fill in gaps, correct misleading wording, and change or remove irrelevant information.
So far evaluation metrics have not been discussed. Depending on the organization there may be a published evaluation process or metric. Some organizations rely on a simple calculation using cost, risks, and potential benefit in dollar values. If this is the case, spend some time checking the math.
Many organizations use a broader metric for evaluation than just a simple number-crunch value. For example they may incorporate things like alignment to core business values, customer visibility, positive public exposure, marketing value, or other non-quantifiable criteria just to name a few. Project proposals that are evaluated by criteria that can’t easily be quantified are left with proving value that is dependent on subjective interpretation.
If the project proposal template allows for it, add a section at the end to list the evaluation criteria along with an explanation as to how this project meets that criteria. If the template does not allow for editing the sections, then make a point in the body sections to point out how the project meets the criteria.
In either case, the evaluators may have different opinions about the evaluation. However, not documenting exact points will leave the interpretation entirely up to them, and they may not read every word in the proposal.
Hopefully, you, your team, and anyone who has reviewed the project proposal up to this point has been reviewing the document for grammatical errors, and you have been correcting them as you find them. It never hurts to take one more look. A couple of grammatical errors can be overlooked but many errors cause alarm, which is never a good thing when the reader is a project evaluator.
It is also important at this point to review for continuity errors. If the document has references to product names, are the references consistent? Make sure that either abbreviations are not used, or they are used consistently after a statement of the full name is used in the beginning of the project proposal.
Check for the use multiple synonyms for the same term. For example, the words application and software are commonly interchangeable. It is best to check if there is an industry or company standard. If there isn’t one, make a choice and stick with it.
Check for parallel structure with phrasing in list, as well as between sections of the document. Bullet items in a list should be worded with similar structure for continuity. By mixing phrasing structure you risk losing the reader’s ability to follow your thought process. The same goes with sections within the body. It is okay to have one section as a list of bullets and another a paragraph of text, but you don’t want two bullet lists with different structures next to each other in the document.
In the final step of preparing a project proposal, you want to review the document to see what stands out to a reader. Much like a resume, you want the most important facts to jump out at the reader, especially if they are only scanning the document.
5 Tips for visual modification:
* Bold key words and phrases
* Use color sparingly to create emphasis
* Use a different font or italics to indicate extra information
* Breakout multiple thoughts in text into individual bullets
* Use offsetting to create visual breaks
Depending on the medium for submitting proposals in your organization, you may or may not have a lot of room for formatting text with fonts, color, or even bold or italic lettering. In this case, check to see if you can use special characters to create bullets or use spaces and extra return characters to make text stand out.
Conclusion
If you followed these 10 steps, you should have a fairly complete project proposal ready to submit. If not, don’t worry, the steps can be iterative. As you and your team make new discoveries during this process, you may need to revisit areas of the proposal that you have already completed. Just remember, it is okay to redo work.
Interview with Doretta Gordon, Director at Southwest Research Institute.
Gordon is a director in the Training, Simulation & Performance Improvement Technologies Divison of SwRI. As part of her role, Gordon is responsible for working on proposals for both large external government contract awards and internal operation initiative type project proposals.
In both types of projects Gordon works on, the proposal templates are almost always predefined by either the company awarding the contract, or her own company. However, she says that there is a fair amount of leeway within the sections of the proposal templates. In fact, one of the most difficult parts of using a predefined proposal template, according to Gordon, is guessing the best way to present content within the section. “You are guessing how people will read your response, as well as guessing what they really want to know in the first place. Formatting plays a big role in delivering the message”
On the topic of project evaluations, Gordon says, “even if the request for a proposal states it is not dependent only on cost, cost is still a very important factor. In either case, it is very important that you document how you come to your figures in the cost breakdown. A low ball number without proper explanation will get thrown out quickly.” Gordon went on to explain how in some large scale projects, the team coming up with the cost figures is kept separate from the team writing up the procedure. In these types of scenarios, it very important that the section that explains the solution scope is properly documented.
On the subject of what to watch out for, Gordon said that a common mistake made when writing proposals is forgetting to check to make sure that the solution proposed matched the problem originally stated. Proposal teams have a tendency to get carried away with adding in additional scope, and forgetting to check the validity against the need of the project. “Once I was told that we gave a Cadillac proposal for a Yugo problem.”
One technique used in Gordon’s company is a “Pink Team and Red Team” approach for checking validity. During the writing process, a pink team is brought in to review the proposal. This pink team is made up of people within the division that have some understanding of the department working on the proposal, and they interact with the proposal team during the writing process in order to help make corrections. After the proposal is complete, a red team is given the proposal to edit and check validity of the solution. Unlike the pink team, the read team has no prior knowledge of how the proposal was put together. The purpose of this test is to get an understanding of how the proposal will be perceived by an outside party, and to test the overall validity of the proposal.
Websites
Project Proposal Writing Guide for THE REGIONAL ENVIRONMENTAL CENTER
for Central and Eastern Europe
Free online tutorial: IT Proposal Preparation Primer by Resource Management Systems Inc.
Proposal Template Software offered by ProposalKit.com
Example of the ProposalKit.com software
Project Management Institute (PMI), world’s leading not-for-profit membership association for the project management profession
Helpful books on Projects and Project Proposals
Project Management Body of Knowledge
Proposal Planning & Writing
Very well organized and straight forward. I hadn't ever though of the concept of a project being universal which allows for a systematic approach. Great job. The hyperlinks are sweet too.
ReplyDelete