Proposal writing is arguably the most important thing you are going to do as a government contractor because:
1) The quality of your proposal is what determines whether you win or lose any given opportunity
2) The speed at which you can pump out quality proposals will largely determine how fast you can grow.

So you need to get good at proposal writing and proposal management, and you need to be able to do both quickly.

So with that in mind over the courses in this section we will present a process for writing proposals that we believe produces the highest quality product in the least amount of time, and if you follow our archiving recommendations each proposal your write will take less time than the one before.

Course structure: 

Section 1: Laying the groundwork:  During these classes we are going to talk about:
-Taking an agile approach to proposal writing and workplanning
-Building a compliance matrix
-Setting up a proposal room and IT infrastructure to help you build a proposal

Section 2: Setting the strategy for your proposal: During these classes we will talk about:
-Setting a strategy based on the evaluation regime
-Building a winning team

Section 3: Writing: During this section we will talk about best practices for writing a proposal including:
-Turning your compliance matrix into a first draft
-Writing best practices
-Reviews and compliance checks
-Proposal graphics


Many of you may be familiar with Agile processes from software but for those of you that aren't here is a very quick overview of Agile software development which I hope will demonstrate why it has become the best practice approach to software development, and in the next section we will talk about how these principles apply to proposal writing.


So imagine that you need to write a complicated bit of software. One way to approach building it would be through what is known as Waterfall Development, which is still the predominant approach used for government proposal writing:
1) Do a bunch of customer interviews to figure out exactly what people want

2) Write out all the features the customers wants and group them by the kind of work they involve
3) Create specialist teams (e.g a graphics team, a database team, a user experience team, etc) and give the appropriate features to them

4) Then build a detailed workplan that defines when all the features will be built all the teams deliverables and due dates
5) Then have each team go off to produce their piece per the workplan
6) Integrate the sections and release the product to grateful customers

Pros of this approach:
1) Specialist teams can produce quickly
2) Software is so structured that you should be able to identify integration points easily
3) You have a pre-defined release date that you can announce to customers

Cons of this approach:
1) You only talk to customers at the very beginning so if you get any of their feature requests wrong (or misinterpret them) you will build a product people don't really want
2) People NEVER estimate the time needed for Integration correctly
3) The time needed for integration almost always throws off the plan leading to buggy software being released


Agile takes a different approach. In agile instead of making a single project plan that will guide the work for the entire build you build the software in short sprints, so it would look at bit like:
1) Do a bunch of customer interviews to figure out exactly what people want
2) Write out all the features the customers shared and prioritize them (so the most important features first)
3) Create cross-disciplinary teams (e.g each team would have a graphics person, a database person, a user experience person, etc) and give them the two or three most important features

4) Give the team a due date to complete those core features (a sprint)
5) Once the first sprint is complete take the resulting micro-bit of software and get customer feedback on it
6) Based on the feedback and the initial features list and build the next most important features into the software in another sprint
7) Continue adding features through short sprints and frequent engagement with customers

Pros of this approach:
1) Because the customer is engaged throughout the process the ultimate product tends to be more valuable to the customer
2) Because integration is done throughout coders stay aligned reducing the total time spent on integration

Cons of this approach:
1) Inter-disciplinary teams tend to be a little slower than subject matter expert teams

What does Agile proposal writing look like?

So I hope you believe, or will accept for now, that agile has proven to be a FAR better way to build software, so lets talk about how it applies to proposal writing

1) Read the RFP to figure out exactly what people want
2) Write out a compliance matrix and prioritize the requirements
3) Create a cross-disciplinary team (e.g the team would have a management person, a pricing person, and a technical person), or teams if it is a larger proposal with distinct sections, to build a workplan with priorities and page limits for different requirements
4) Look at the time available to build your proposal and break it into writing sprints (e.g.)
  a) An light outline sprint
  b) A heavy outline sprint
  c) A first draft sprint
  d) A final draft sprint

5) At the end of each sprint take the resulting draft to the full team (if there are multiple writing teams)/ internal reviewers to get feedback and do any integration between team members needed. Once integration and review is complete the resulting doc will become the "master" draft that all teams work off of for their next sprint
6) Continue conducting short sprints and reviews until you have a finished document

I know this is a high level discussion of agile but in the next classes we will give you a more detailed view on what is being done at each step.

What if the prime on the contract isn't utilizing an agile approach? This actually isn't as big of a deal to work around as you might think. In waterfall proposals each writing team gets their section of work, and the writing teams are generally aligned with companies (e.g. you as the sub write the section you are brought in to do) As a result you can institute whatever policy you want