How to Write a Software Development Proposal
The purpose of a software development proposal is to convey a solution that will be read by business people, so keep it simple and to the point; stay away from technical terms as much as possible. The following outline can be used as-is to prepare a successful software development proposal. It is important to keep in mind that the people that you are going to present the proposal to don’t have a lot of time to read a lengthy document. You can take it from me, I have written hundreds of proposals over my 20-plus years in information technology: business people want just enough information to allow them to make an informed decision.
If you are responding to a Request for Proposal (RFP) and must respect a certain page range, because the pages are pre-printed or the content requirements force you to have an excessively long proposal, then consider using an Executive Summary. i have added a section outlining how to prepare one below.
I have seen templates and discussion that advocate proposals that run on for 50 or pages. Believe me, you will lose the business executive’s interest after the fifth page. Once the proposal is accepted, the design documents will naturally be more detailed as they will be destined for the project team and will be the working blueprints for the system. This will apply to most clients but (yes there is always a but) if the proposal is in response to a Request for Proposal (RFP) then you must adhere to the RFP. Also a government or military agency will probably have stringent guidelines on how to prepare a software development proposal and may include several pages (10, 20, 30, 50 or more) depending on the complexity of the system. This rule still holds true for large organizations which may have a formal proposal process especially if they are a public corporation and must adhere to any Sarbannes-Oxley or ISO regulations or standards.
If the proposal is over 20 pages, then you may consider providing an Executive Summary which is a one-pager of the sections in the proposal. You can even provide an Executive Summary in a PowerPoint format. If you are planning on using an Executive Summary in the software development proposal presentation, present the proposal using the Executive Summary and the executive can read through the proposal at a later moment in time, like during a business flight.
The following outline is actually a good template that you can use to prepare your own software developemnt proposal. I always keep the Elevator Pitch rule in mind when preparing a proposal, and you should too. Basically the Elevator Pitch stipulates that your proposal should not be much longer then the time it takes to take an elevator from the ground floor to the top floor of a building on your way to present a proposal.
With a Subtitle or Summarized Information on the Proposal
The proposal should have title and a sub section summarizing the context of the software proposal. You also include the name of the name of the division, service, department or organization that the project is intended for.
If you are responding to a RFP (Request For Proposal), then include any information that is required or listed as mandatory in the RFP. I also seen RFPs that request you put the approval signatures in addition to the title on the first page, but in this example, I put the signatures on the page with the Changes section.
Table of Contents
On the next page you should include a table of contents listing the major sections of the proposal. You can optionally include the page numbers if the proposal exceeds 5 pages or if it's required by the RFP.
This section is crucial to the process, whether it is response to a RFP or from this template or from some other source. This section documents the confirmations that the project is a go and provides a binding agreement between the various members of the project. You should never start a project until you have obtained all the necessary signatures and have a commitment from the project champion and stakeholders to begin the project. Otherwise you might find yourself in a bind if the project is cancelled or if the scope of the project changes or the deliverables.
With the Approvals in place, scope and deliverables changes are much harder to make and if there are disputes, having signed approvals will provide a clear(er) understanding of what was agreed upon. Of course there is always a question of interpretation.
The Approvals should include the name of the person, their title, followed by their signature and finally the date when the document was signed.
The Changes section provides a log of all the changes that were made or will be made to the Software Development Proposal document. It doesn't document any changes to the scope of the project itself or any other aspect of the project. The Changes section should include at a minimum the name of the person making the change, the date of the change and a comment or description of the change.
Date of Change
Description or Comment
Glossary & Acronyms
List any terms or acronyms and their definitions. Don’t assume that everyone knows the meaning of terms or acronyms, especially if you are planning on using external consultants and the terms are internal, embedded within your corporate culture and lingo. Every organization has their own lingo and acronyms. It is ok to use them in the proposal as long as they are properly documented.
Also if any industry specific acronyms are used, they need to be documented as well so that everyone has a clear understanding of the meaning of the terms and acronyms and formulates better interpretations.
The following acronyms are from the current template. They are provided as an example.
RFP: Request For Proposal
ROI: Return on investment
CAGR: Compound Annual Growth Rate
IT: Information Technology
CAPEX: Capital Expenditure
UoM: Unit of Measure
The Scope of the proposal should outline at a high level the overall project details, what is included and excluded. The scope should provide an overall description, the length of the project, the major objectives. What are you trying to accomplish with this investment in the proposed software development project.
This section will include the start and end dates (estimated). Be sure to build in a buffer and plan for contingencies. A good Rule of Thumb is to add a 75% buffer to your timeline.
The project members should include the project champion and stakeholders. The champion is usually an executive who drives the overall project and budget. The stakeholder is usually an internal promoter or sponsor. They can also be the champion depending on the scope of the project and or the type of organization that is requesting the software development proposal. The remaining list are typical roles that people perform in a project.
The following is only provided as an example of the type of roles project participants may have. Some people may have more than one role. Depending on the scope of the project, the project members list can be very lengthy or the same person may assume different roles.
The list should contain any information that properly identifies the person, their role within the project, how to reach them and what are their responsibilities. You can include other information depending on the RFP or the type of organization you will be working with and their internal policies.
Most templates that are available define this section as “Business Problem” or “Problem Statement” however I have often encountered business leaders who take offense to the fact that they have a problem in their business unit or process. I remember one director literally throwing me out of her office because I had stated that we were fixing a process and she told me that it wasn’t going to be someone from IT (Information Technology) who was going to dictate if she has a problem with her processes or not.
So be careful with the wording. I always use the term “Business Opportunity” because in the end, the proposal is in response to a business opportunity to improve a process, support a process or automate a process
How the system will satisfy the requirement
Affected business process, situation, problem
How will the proposed solution will improve the target business area
What need is being addressed
How is the current project going to address it
In Solution Overview section, you can provide a high level overview of the system. This overview can include a navigation map if the proposal is for a web site or web app. You can also include a flowchart of the process flow. Also you can include a diagram of the major components of the system.
The objective here is to give the person who is making the decision enough information so that they understand what the system is so, how it will work, and what are the major building blocks. Of course this is only a guideline as an organization may have a formal format that defines what you will need to furniss in the proposal, especially is you are dealing with a government agency or the department of defense.
Features & Deliverables
This section provides a mechanism to map a feature of the proposed system to a tangible deliverable. I have also seen this section containing a time estimate to complete the deliverable, but I don’t like using this because it is too restrictive and creates a tie in. When working on the project, the deliverables may not line up exactly as written down, so if you have committed on paper to finishing a deliverable by a certain time, it removes or lessen any elasticity later on when you are actually doing the project.
Another column that can be added is the Release that the Deliverable belongs to. This is handy if the project will be delivered over a longer period of time and there will be several releases. This can also apply to a Agile or Lean based project where each feature or User Story belongs to a Release.
The concept is simple; for each feature in system, provide the name of the feature, a short description and which deliverable will satisfy the feature requirement.
Budget & ROI
The Budget & ROI is probably the most important part to some executives. They are all anxious to know how much the system will cost them or how much of an impact this project will have on their department budget. This is especially true if the project wasn’t included in the Capex at the beginning of the fiscal year.
Sometimes, even if the project was budgeted for, another project may take precedence over the current proposal and funds can be diverted from their intended source. There is often a bit of political wrangling going on at the executive and management level to get a project off the ground and there is often unforeseen circumstances that may take precedence over planned projects.
So be prepared to work with your stakeholder to help with negotiations or be flexible and proactive to provide a working solution if a budget situation goes sideways. It is better to adapt the project to the budgetary reality, even spreading the system deliverables over a longer period of time or even walk away from the project. It is far better to walk away then to have worked on a project and not get paid and have to resort to litigation down the road.
The following table is for demonstration purposes only to you give you an idea on how to prepare a budget. Naturally you will need to add your own line items to fit your project. Then you fill in the quantity, the unit price, the unit of measure and the line item total. Then tally up the line item totals at the bottom.
This will provide a good picture of the investment required to do the software project. Most executives that I have worked with like to know what the rate of return will be or how much this project will cost over time, so I also include a simple ROI value and a CAGR, either using my own estimates and assumptions (which must be explained) in the proposal or using the furnished estimates and assumptions.
Training (Time + Materials)
The ROI calculation is very easy. Basically the formula is gains - cost divided by cost. The formula is provided below:
ROI = (Gains – Cost)/Cost
The only downside is that the calculation doesn’t take time into account, so the ROI is good for short term projects but for longer term project I generally include a CAGR (Compound Annual Growth Rate). The CAGR calculation is a year over year rate of return for a certain moment in time.
The CAGR formula is:
CAGR = ((End Value/Start Value)^(1/ Number of years))-1
The first part is the division of the end value by the start value. The result is raised to the power of 1 over the number of years invested. The resulting value is subtracted by 1.
In this section you list the business benefits that the software project will provide. They can be listed in bullet format as long as they tie in with the overall objectives. They should demonstrate how the software or system will enhance the business value.
In a nutshell, how is the proposed solution going to help the business be more successful and attain its statement objectives. Use positive words and sentences.
The constraints section should list any tangible and intangible constraints that you can foresee. This can relate to equipment, some seasonality factor like a production plant shut down which most plants do at least once a year as an example.
Try to downplay the constraints or paint them as being minimal. Don’t list any negatives aspects of the software or system or if you have to, then provide workaround solutions.
© 2012 Kevin Languedoc