A Project Proposal is a document which describes the solution to a problem in a series of steps that can be implemented. The Project Proposal also talks about the proposed way to implement to the solution, the timeframe required for the solution to be implemented and the cost involved in implementing the solution.
The different elements that are present in a Project Proposal are provided below.
- Overview
- Proposed Solution
- Process Map / Mind Maps
- Scope of Work
- Wire Frames
- Assumptions
- Out of Scope
- Technology
- High Level Project Timeline
- Browser / Screen Resolution Compatibility
- Deliverables
- Dependencies
Simply put, the idea behind coming up with a Project Proposal is to Set Project Vision, Define Scope of Work, Describe Deliverables, Specify Deadlines and Get Approvals from Stakeholders for Project Initiation.
1. Overview
This section is provided to give a small brief about the client, their line of business and how they carry out business processes at the moment and why there is need for improvement in the way they go about their business.
2. Proposed Solution
The Proposed Solution section gives a brief of the solution at a very high level. It does not dive into the details and the nuances of the solution proposed but rather talks about how the proposed solution solves the business problem that it is intended to solve.
3. Process Map / Mind Maps
Process Maps and Mind-maps are generally used in a Project Proposal to pictorially depict either the AS-IS state of the system or TO-BE state of the system. These are used to give a bird's eye view of the bigger picture behind the project.
A quick look at this section of the Project Proposal should enable any stakeholder to get an overall picture about the intended project and the impact that the project would have on the business.
4. Scope of Work
Th Scope of Work section gives a brief about the different features / functionalities / services / products that would be build as part of the Project. The main idea behind defining the scope is to bring all the Project Stake-holders on to the same page with regard to what is considered in scope and what is considered out of scope.
5. Wire-Frames
Providing low-fidelity wire-frames of the TO-BE system is increasingly being adopted as a practice in the current IT business scenario. These low-fidelity wire-frames are usually hand-sketched / white-boarded.
The wire-frames are used to show a representation the various stakeholders as to how the TO-BE system would look like with regard to the flow of processes / features.
While this is not considered to be a mandatory requirement for a Project Requirement, it is often included to attract clients into doing business with them.
6. Assumptions
In the world of Information Technology, a Project Proposal is created as part of the Pre-Sales process. During the Pre-Sales phase, the Business Analysts talks to the client and tries to get a high level understanding of the client's business requirement.
Considering that the Requirement Gathering sessions are not yet complete, the Business Analysis might not have all the answers about the client business and the requirement at hand. That is where Assumptions come into play.
The assumptions section contains a list of items that were considered to be in a certain manner while the effort estimation and the rates for the project were calculated. For instance, while building a proposal for a new website, one of the assumptions could be, 'Branding Guidelines & Logo to be provided by the client'. This assumption clears the air by stating that the liability to provide Branding Guidelines and logo lies with the client.
If the client requires branding to be part of the scope, it shall be provided, but at an additional cost. In a way, assumptions help in avoiding scope creep and cost over-runs. In addition to such generic assumptions, there could be specific technical and functional assumptions as well.
Examples:
The Client shall provide the necessary data inputs for User Acceptance Testing (UAT Testing)
The application shall only accept JPEG & PNG file formats in the 'Upload Picture' functionality
The size of the file / file(s) uploaded to the application shall not exceed 2 MB
7. Out of Scope
When a Project Proposal is created, it usually has a cost associated with it. For the cost to be arrived at, the Scope must be defined. Part of defining scope is also making sure that all the stakeholders involved are aware as to what is in scope and what is out of scope. For instance, if the application being developed will not have multi-lingual capabilities, it makes sense to put it in writing.
Such out of scope definitions go into this section.
Example:
- Multi-Lingual Capability shall be considered out of scope to this project
- Multi-Currency option during the check out process shall be considered out of scope to this project
- Mobile / Tablet application development shall be considered out of scope to this project
8. Technology
This section contains details of the technology platform in which the IT solution would be implemented. Both Hardware and Software specifications are provided in this section.
The decision to go ahead with a particular technology will be based on many number of parameters including the Client current suite of products, client's brand / product preference, scale-ability, etc.
For instance, an enterprise client that uses Microsoft suite across the company might want to go with Microsoft products.
Example:
LAMP Stack, MS Share Point, etc.
9. High Level Project Timeline
Project Proposals also have a high level project plan that indicates the approximate time to completion of the project and the expected timeline of intermediate deliverable items if any. The timeline will not be an exact one but will give an idea to the stakeholders that it might take X number of weeks from start of the project to project completion.
The timeline will also have the important phases in the project marked on it.
10. Browser / Screen Resolution Compatibility
The number of screen sizes / browsers that the application / website must be compatible to will impact the cost. Hence it is very important to set this right and document the browsers and screen resolutions that the new application will be compatible with.
Example:
11. Deliverables
The list of items that will be delivered to the client through out the life of the project will be listed in this section.
The list includes the following
- Detailed Scope
- Detailed Project Plan / Sprint Plan in the case of Agile Development
- Wire-frames
- Mood Boards
- Visual Designs
- Sprint-wise Release Plan
- Application Source Code and Databases
12. Dependencies
The dependencies that could in any way affect the delivery of the project should be listed in this section for the knowledge of the stakeholders.
Dependencies could be something like, 'A point of contact from the client's side to expedite the stakeholder approval process'.
Some clients might have multiple development partners working with them. There might be deliverables that the first partner might have to deliver for the second partner to kick-start work. In such a scenario, the second partner would list the deliverable from the first partner as a dependency that could affect the delivery of the project.