The purpose of such a 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.
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.
Proposal Length Is An Important Factor To Consider Beforehand
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 that 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.
Include An Executive Summary For Convenience
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.
Think Carefully About The Template Of Your Proposal
The following outline is actually a good template that you can use to prepare your own software development proposal. 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 than 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.
Subtitle or Summarized Information on the Proposal
The proposal should have a title and a sub-section summarizing the context of the software proposal. You also include the name of the division, service, department or organization that the project is intended for.
If you are responding to an RFP (Request For Proposal), then include any information that is required or listed as mandatory in the RFP.
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 five pages or if it’s required by the RFP.
This section is crucial to the process, whether it is a response to an 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.
Glossary and 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 its 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 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 contains are typical roles that people perform in a project.
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 we have often encountered business leaders who take offense to the fact that they have a problem in their business unit or process.
Be careful with the wording. 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.
In the 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 and Deliverables
This section provides a mechanism to map a feature of the proposed system to a tangible deliverable. 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 lessens 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 an Agile or Lean based project where each feature or User Story belongs to a Release.
The concept is simple; for each feature in the system, provide the name of the feature, a short description and which deliverable will satisfy the feature requirement.
Budget and 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 than to have worked on a project and not get paid and have to resort to litigation down the road.
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.