Archive | proposal writing

Proposal Writing Blog Series, Day 5: Cost and Past Performance

Aug 13th, 2010View Comments

This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

Cost Section

During the Reviewing the RFP Process section, I mentioned that usually the RFP has a Section B, which details the way the organization wants the cost information to be shown. There are times where they just want you to copy and paste your cost schedule. Other times, they want your cost broken down by a timeline that they specify, or they want you to.

Past Performance

Like resumes, having a Past Performance template will help in having uniformity in the proposal, and make it easier to add the information. Usually, an organization wants the following information to be covered in a past performance:

Company/Division Name
Period of Performance
Title
Contracting Agency
Point of Contact
Contracting Number
Type of Contract
Task Requirements
Level of Effort (Labor Hours)
Total Cost of Contract $ Value
Original Completion Date
Current Completion Date
Program Director/Manager

In the majority of the RFPs I have seen, they usually will tell you what information they want in a past performance, and how many of them they want in the proposal.

However, if they don’t specify, ensure that you have at least three past performances where the work was of similar scope and size. The Past Performance section is usually in the body of the proposal. However, if the organization doesn’t want it to be part of it, you can usually place it as an appendix.

End of Blog Series

We have come to the end of the Proposal Writing Blog Series:

I hope that you were able to learn a thing or two. Please check out the handbook that is filled with examples and more tips.

proposal, proposal cost, proposal past performance, proposal writing handbookproposal writing, technical writing

Proposal Writing Blog Series, Day 4: Technical Solution

Aug 12th, 2010View Comments

You have written the Management Approach, and now it’s time to start talking about the actual solution.

You have done all the analysis, talked to SMEs, and really thought about the best way to solve the organization’s problem. It is now time to write it on paper. The Technical Solution section is a great way to do some preliminary thinking of the future solution that you will present to the organization. Even if you do not win the contract, you will have the foundation in developing a sound solution for future contracts. It is like a Concept of Operations (ConOps) document within a proposal. If you don’t know what a ConOps is. A ConOps is a useful technical document that can aid you in envisioning the perfect system to tackle a current issue that you are trying to solve. One thing that I will stress is that you should only offer one solution. You might want to offer an alternative as well. Don’t. It will make you look indecisive. You are the expert, so you tell the organization what it is they need.

Here are the main sections that a basic Technical Solution section usually has:

Introduction, Including Section Overview

A Technical Solution section has an introduction. As I stated before, the person reading the Past Performance section is usually not the same one reading the Technical Solution section. Therefore, you have to treat it as its own document, so a person could rip it out of the proposal and still understand what is going on. You should introduce your technical solution and briefly let the reader know how the section is organized.

Client’s Issue

Before you can discuss the proposed solution, you have to give stakeholders a bit of history of the issue you are trying to solve. The background and history of the current issue is very important because you want to show stakeholders that you fully understand how the issue evolved. It will also help you in designing a better solution.

If there is already a current solution in place, then you want to discuss that as well. You want to detail everything about the current solution and/or issue. When you are writing about the current issue, you want to ensure that you get everything down from your interviews with Subject-Matter Experts (SMEs and stakeholders. If you don’t fully understand what is currently going on, how can you find the proper solution?

Therefore, take your time in gathering everything you can about the current issue and its history.

Technical Solution Description

You have done your research, and you have written all you could about the current issue the organization is having. It’s now time to discuss how to solve the issue. You want to really take a week or longer to really come up with a solution that will be better than what is currently in place. You want to start off by giving a high-level overview of the future solution. Please make sure that you use “will” and not “shall.” The latter is requirements talk.

After giving a high-level overview, you want to go into the detail. You want to explain the reason you approached the issue the way that you did. This is kind of a bridge between the organization’s current issue and your solution. It gives the Technical Solution section a better flow.

You want to discuss any policies and constraints that the future solution will have. Additionally, you want to ensure stakeholders that you will adhere to any current and near-future policies that are in place. Also, that it is interoperable with other systems. Organizations and government agencies have realized the importance of being able to work alongside other groups, so if you can show that your future solution can do that, then stakeholders will be almost sold.

The impact that the future solution will have to the users, everyday operations, and other systems is the best way to conclude this sub-section. You want to reassure stakeholders that you have thought about this, and you will ensure that everything is smooth sailing, or as near to that as possible. This is something you should go into further in the next sub-section, Implementation Plan.

Implementation Plan

If the organization already has a solution in place, you want to discuss how you plan to phase that solution out, and implement yours. This includes processes, equipment, and strategies. Also, you want to discuss how you will measure the plan to ensure that it is highly effective. This could be done by having a schedule that includes milestones. If you reach the milestone before or on schedule, then you know that you are on the right track. You might be thinking, “I haven’t even gotten to the point of creating a full schedule.” The best way to handle this is by breaking things down by phases.

You can explain to the organization that you will work with them to create a more detailed implementation plan and schedule when you win the contract. However, you still should show the organization that you have put some thought as to how you will implement your solution.

One thing to remember is that even though you have done tons of research, interviewed SMEs and the client, and have applied your expertise, there are always going to be a few gaps. This is where assumptions come in. You will have to state the assumptions, why you made it, and why you weren’t able to find out that information before writing your proposal. If you have done your homework before you made the assumption, then usually the assumption has a likely chance that it is true.

You can now start writing the Executive Summary and Cover Letter.

proposal management, proposal writing, proposal writing handbook, technical solutionproposal writing, technical writing

Proposal Writing Blog Series, Day 3: Management Approach

Aug 11th, 2010View Comments

We have discussed the Cover Letter and the Executive Summary. We now get to the first main section: The Management Approach. I’ve written project plans for various projects. The Management Approach is a similar concept. This is where you assure the organization that if you win the proposal, you have a plan in place that will monitor the project to ensure that it remains on time, within cost, and on task. The Management Approach usually contains the following areas:

Program Management Approach
Roles and Responsibilities
Resumes
Program Monitoring
Program Schedule and Timeline
Contract Deliverables
Training

Program Management Approach

In this sub-section, you let the organization know the way that you will manage the project. There are several ways to do it:

If the organization wants to be aware of everything occurring with the project, then you want to ensure them that you will be working closely with them to do this.
If the organization is more hands off, then you want to let them know that you have experienced project managers who will be on top of things.
If the organization wants to have more of a team environment, then you want to ensure them that you have the proper team to ensure the project is successful.

Roles and Responsibilities

The roles and responsibilities are important for the success of the program, so you have to show the organization that you have setup the best team to ensure that this happens. A great way to make it visually easier for the organization to see roles and responsibilities is by placing them in a tabular view. The table column headings you want to have are the following:

Role – The job role title
Description -A high-level summary of the user role
Responsibilities -A bulleted list of the main responsibilities that role will perform.

Unless the RFP, or Statement of Work, wants the resumes as a separate section, you want to place the resumes in this sub-section.

Program Monitoring

In this sub-section, you discuss how you will monitor the project to resolve any issues that might come along. Some of the things that you might mention in this area are if you have any kind of review process in place. Also, will you be providing weekly and/or monthly progress reports to the organization?

Program Schedule and Timeline

An organization is not going to expect you to have a detailed project schedule on a proposal. However, you want to have some preliminary sketch of what is to be expected. You want to show the organization that you put some thought in the most effective schedule for the implementation of the solution.

Contract Deliverables

Documentation is very important in any project. Therefore, you want to tell the organization that you will have some documents that you will deliver to them. There are standard documents that you will more than likely have on your list. Here are a few:

Project Management documents (e.g. project plan, training plan, configuration management plan, test plan, etc.)
Risk and Action Items logs
Progress Reports
Quality Assurance Plan

Training

If users will need to be trained, then you want to write a brief summary about your intent on providing training, and a high-level description on how you plan on doing it. If you will be writing a separate training plan, please indicate that, and that you will be working alongside them in developing one.

management approach, proposal, proposal writingproposal writing, technical writing

Proposal Writing Blog Series, Day 2: Executive Summary

Aug 10th, 2010View Comments

Yesterday, we discussed how to write the cover letter of a proposal. The Executive Summary should be treated like a miniature version of the proposal. It summarizes the high-level points in the Management Approach and Technical Solution. As I stated when discussing the cover letter, you should write it after you have finished the other pieces being that it is a summary.

As with the cover letter, the Executive Summary is the only other section that could be read by anyone. By knowing this, you have to keep the technical jargon to a minimum. Sum up the main points, even of the Technical Solution section, in a way that anyone can understand.

It also is a good area to start building that rapport with the organization, and setting the tone to make them feel and understand that they are the main focus.

A great way to organize the Executive Summary is first stating the problem. The Executive Summary is also a way to show the organization that you fully understand their problem. By doing this, they know that you have tailored a solution that works for them.

The second paragraph should discuss your solution and promise to ensure that the work is always at its highest quality. Please remember to keep the jargon to a minimum. Anyone, regardless of their knowledge of the intended subject matter, should be able to pick up the Executive Summary and understand what you are trying to say.

The third paragraph should discuss your organization and its management approach. Even though it’s discussing your company and its strategy, you should tailor it so it still makes the client feels that it’s all about them.

executive summary, proposal writing, proposal writing handbookproposal writing, technical writing

Proposal Writing Blog Series, Day 1: Writing the Cover Letter

Aug 9th, 2010View Comments

After you have made the decision to submit a proposal, dissected the RFP bit-by-bit, and done extensive research, it is time to write the proposal.

The first thing the organization will see is the Cover Letter, or Letter of Transmittal. As with the Executive Summary, which I will go into more detail when we reach that section, I recommend working on the cover letter after you have finished the body of the proposal. The reason being that the Executive Summary summarizes the main points of each section, and the cover letter is a mini-Executive Summary. It should only be one page, and written so you instantly grab the reader’s attention. Imagine how many proposal he/she reads during the RFP process.

Also, multiple people will be reading your proposal, so the person reading the management approach might not be the same person reading your technical solution. The cover letter is a great way for all the people involved to get the gist of the entire proposal without having to read each section in detail. If the cover letter is impressive, they will want to flip to read the rest of the proposal. Here is a great way to write the cover letter:

The first paragraph should let the reader know you understand the issue the organization is trying to solve. Do not go into a canned response thanking them. It will be done by the majority of the submitters. Instead, show that your company fully understands the issue by summarizing the problem they are trying to resolve.

The second paragraph should be a high-level and brief overview of the way your team will solve their problem. Additionally, it should stress how your solution is unique and will not be able to be done by anyone but you.

If you are responding to a RFP, write the RFP details, like the name, solicitation number, and any pertinent information.

At the end, always finish with a call of action. For instance, something like “Please contact Ms. X if you have any questions or want us to present our solution to your group.”

Now that I am talking about writing the proposal, I will continue emphasizing this point from time-to-time. Please do not forget to have ample time to edit. You do not have to be the best Writer if you are a great Editor. As long as you get down the bulk of the proposal, and you take the time to edit, then you should be fine.

Before you are done with the cover letter and the other proposal sections, ensure that you spell check, and that the organization’s and COTR’s names are correct. Also, that it adheres to the RFP’s formatting rules.

cover letter, letter of transmittal, proposal writing, proposal writing handbookproposal writing, technical writing