The Purpose of 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 RFP and must respect certain page range because the pages are pre-
printed or the content requirements forces you to have an excessively long software development
proposal, then consider using an Executive Summary. i have added section outlining how to
prepare one below.

Proposal Length
I have seen templates and discussion that advocate proposals that runs 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) unless of course the proposal is in response to a Request for
Proposal (RFP) and then you must adhere to the RFP. Also a government agency or military 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 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.

Executive Summary
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 later moment in time, like during a business flight.

The Template
That said, the following outline is actually a good template that you can use to prepare your own
softwaredevelopemnt 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.

Project Title
Sub Title 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 to have the approval
signatures in addition to the title on the first page but this example, I will put the signatures on
the page with the Changes section.

Table of Contents
On the next page you should include a table of contents that list the major sections of the
proposal. You can optionally include the page numbers if the proposal exceeds 5 pages or
required by the RFP.

Approvals
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.

Nam
Title/RoleSignatureDate
e
       
 Nam
Title/RoleSignatureDate
e
       
       

Changes
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 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.

Autho
Date of ChangeDescription or Comment
r
     
     
     

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

Scope
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.

Timeline
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.

Project Members

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 a 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.

Team Member Role Contact InformationResponsibilities

  Champion    
  Stakeholder    
  Project Manager   
  Architect    
  Analyst    
  Developer    

Business Opportunity
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

Business Statement How the system will satisfy the requirement

Affected business process, situation, How will the proposed solution will improve the target
problem business area
What need is being addressed How is the current project going to address it
   

Solution Overview
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.

Featur
DescriptionDeliverable
e
     
     
     

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.

Unit
Project Item Amount UoMTotal
Price
       
Software license
 Unit
Project Item Amount UoMTotal
Price
Machine(s)        
Server License        
Database license        
Development Consultant        
Project Management        
Training (Time +
       
Materials)

ROI

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.

CAGR
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.

Benefits
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.

Constraints
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.