The Proposal Document, which may be referred to as the Business Case, explains the problem together with a description of how the problem will be solved and includes a high-level estimate of what it will cost to develop and deploy the solution.  

Editor's Note: This article is excerpted from chapter 3 of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch.

For an external project, the proposal planning will begin for the development company after they receive a Request for Information or a Request for Proposal from a prospective client. The client company will have completed the Project Concept and will have been through an internal approval process before sending out the RFI or RFP documents to prospective vendors. For an internal project, the Project Proposal will be based on the approved Project Concept.

The Project Proposal Document will include a high-level description of the project and the proposed solution. The Proposal will be submitted to senior management (or to the client) for approval to move on to the project definition stage of planning, where the Project Charter and Marketing Requirements Document are created. A Project Proposal can be a very detailed document, or it can be a very high-level, conceptual document with a lot of open issues that will need to be addressed later in the planning phase. The accuracy of the estimates and costs are contingent upon the level of detail contained in the proposal. An external project will require a much more detailed proposal than an internal project. The client (whether internal or external) will be unable to approve the project to move ahead without a pretty good idea of the time, cost, and effort involved in the project. If you are asked to submit estimates for a RFP document, be sure to document the accuracy of your estimates and any assumptions used to come up with the estimates. If a disclaimer is necessary, include it. For instance, if you are not sure how you will be able to solve a specific problem due to the immaturity of the technology being proposed, clearly state this on the proposal. If the client is not told that no one else has solved this problem yet, they may go into the project with unrealistic expectations! Don’t try to tell them what they want to hear just to get the contract. It will come back to haunt you. Remember that the key to keeping your clients happy is to under-promise and over-deliver.

The following information will typically be included in a Project Proposal Document:

• Executive summary
• Corporate and cultural information
• Previous projects and clients
• Client references
• Development methodologies and processes
• Quality assurance and testing processes and procedures
• Development environment
• Assumptions
• The problem
• Proposed solution(s)
• Constraints, limitations, and risks
• Proposed project phases
• Milestones and deliverables
• The proposed project team
• Costs and payment details
• Terms and conditions
• Proposal submission and questions
• Proposal acceptance and approval

Some sections of the document will not be required for internal projects, such as corporate and cultural information, previous projects and clients, client references, and terms and conditions.

Executive Summary

For external projects where proposals are submitted in response to RFPs, an executive summary is very important. If the company requesting the proposal has never worked with your organization before, the reviewers will need some compelling data that compares you favorably with your competitors. The executive summary should include a brief history of the company together with some high-level financial information. The executive summary is a key input into the decision-making process as many of the proposals are likely to be similar in solution and costs. If a company is investing a substantial amount of money in a project, the decision makers need to feel confident that they are working with a high-quality, reputable company.

Corporate and Cultural Information

This section will contain additional information about your company and the technical department(s) that will be involved in the project. It should include a corporate overview and some information about the company culture. For example, it could include operating values or mission statements for the engineering department.

Explain whether the company has a casual, informal culture or a disciplined, formal one. This information could be very important to the client’s selection of a vendor and will ensure that there are no misconceptions should the project be approved and awarded to your company.

Previous Projects and Clients

This section will contain descriptions of previous clients and projects that were similar to the project the client is proposing or that will demonstrate your

organization’s expertise and experience in project management and development.

For reasons of confidentiality, you may not be able to cite the names of some of your clients or too much detail about the projects you implemented for them. High- level information with a description of the market space that the client operates in, together with a synopsis of the success of the project(s), will be sufficient.

Client References

Here you should list some of your clients who have agreed to give references regarding projects you have implemented for them. Include contact names and titles as well as a brief description of the project(s) you worked on for each client.

Development Methodologies and Processes

This section will include an overview of the project lifecycle and the documentation that is produced during each phase. It should also include information about processes and procedures for such things as configuration management, quality management, source control, security, and any other standard processes used during the development of projects.

Quality Assurance and Testing Processes and Procedures

Quality assurance processes, procedures, and methodologies should be outlined together with an overview of the documentation produced at each step of the lifecycle. There may be testing outside of the quality assurance team that also needs to be accomplished (e.g., performance testing, security testing, product verification/acceptance testing).

Development Environment

This section includes a brief description of the development environment. This will include details about the hardware platform for development, including operating system, design packages, programming software, unit test software, and so on.

Assumptions

This section should contain both organizational assumptions and technical assumptions. Organizational assumptions would include such things as the expectations the vendor has from the client (or the project team will have from the internal client or sponsor) as far as involvement in the project, client responsibilities such as testing or documentation, or client representatives for the project (project manager, for example). Technical assumptions will include items such as the client’s existing hardware, systems, and software that will be used for the project; specific technology that will be used in the development of the product; or consultants who will be engaged for specific areas of development requiring specialized knowledge or skill sets. A lot of assumptions will need to be made to create a Project

Proposal Document. It is important to document assumptions so that there are no misunderstandings later on.

The Problem

This section includes a brief description of the problem. This can be taken directly from the RFP or the Project Concept or can be elicited from the client via phone conversations or meetings.

Proposed Solution(s)

This section contains details about the proposed solution or solutions. There may be more than one way to solve the specified problem, and if this is the case, give the client some alternatives. Different solutions should not be presented if they are just variations on the same theme. For example, do not present the same proposed solution with just one or two details changed. These specific options can be discussed and finalized later if the client decides to go ahead with the project. If you present 350 possible solutions, you will overwhelm the client with too much information, making it impossible for them to make a decision.

Constraints, Limitations, and Risks

Note any known constraints, limitations, or risks that are currently known. This can include things such as the timeline for starting the project. You may need to complete another project before you would be available to work on this one. Any limitations that your company has with regard to technology, knowledge, and skill sets should be identified together with a proposal for how you would manage them should you be awarded the project. Risks are things that are obvious to you based on the information that the client has already furnished. It is important to ensure that you and the client are on the same page with what you consider to be constraints, limitations, or risks for the project.

Proposed Project Phases

The project may need to be developed and delivered in phases either because the client has requested it in the RFP or because you feel that the size and/or complexity or the project warrants it. For example, the project may consist of three distinct products that need to be developed consecutively because of dependencies between them. You may propose that the project be delivered in three phases, with one of the products being delivered in each.

Milestones and Deliverables

High-level project milestones and deliverables are detailed here. These would include the project phases, if relevant. At this early stage of the planning phase, the milestones may be confined to approximate dates for completion of specific documents for the planning phase and a high-level timeline for when each of the subsequent lifecycle phases will be concluded. It should be obvious from the RFP and the solution section whether there are other key milestones or deliverables that should be specified.

The Proposed Project Team

The proposed project team will include the specific roles/positions needed together with some high-level qualifications and skill sets. Individuals do not need to be identified at this point. If it is known who the sponsor and the project manager will be, then name them. If you are not sure, you can specify that you have three project managers, all of whom have at least six years of project management experience, and that one of those managers will be assigned as soon as the project contract is awarded and timelines are finalized.

Costs and Payment Details

This section will contain high-level estimates based on the initial estimates created for the Project Concept or the budget information contained in the RFP. Payment details will contain the payment terms. For example, payment for creating the remaining planning documents may be required prior to the project kickoff. Payment for development may be in installments. Some companies ask for 50 percent up front and 50 percent on completion of the project.

Terms and Conditions

This will include some legal jargon that will most likely be supplied by the legal department. It will contain some disclaimers related to the accuracy of the information contained therein, together with contractual requirements for the approval to move forward with the project.

Proposal Submission and Questions

This section will include the contact information of the proposal preparer, the date and time that the proposal was submitted, and the method of delivery. It will also include any questions the preparer has about anything in the RFP that was not clear. There may be some updates needed to the proposal before it can be finalized and approved if there are open issues/questions at the time the proposal is submitted.

Proposal Acceptance and Approval

By signing this document, everyone involved is in agreement that the Project Proposal Document is accurate and complete and is approved to move forward.

The client (or requester) will typically have a standard process for awarding the project contract to the chosen vendor.

Want to learn more about project management best practices now?  Pick up your own copy of Fundamentals of Technology Project Management, by Colleen Garton and Erika McCulloch - available and on sale at the MC Press Bookstore today!

Colleen Garton

• Email
• Site

Colleen Garton is a highly respected and experienced writer, consultant, and speaker. She is the author of two management books: Fundamentals of Technology Project Management and Managing Without Walls. Recognized internationally as an expert on virtual and global management, Colleen is an experienced and in-demand public speaker for numerous events and conferences around the world. She is also author of the blog Working With or Without Walls.

 Colleen has extensive management and training experience in the United States and internationally, with more than two decades of practical experience in traditional and virtual management spanning multiple industries. She is the owner of the Garton Consulting Group. Before founding the Garton Consulting Group, Ms. Garton held senior management positions at some major U.S. corporations.

You can follow Colleen on Twitter at @ColleenGarton and on Facebook.

---

MC Press books written by Colleen Garton available now on the MC Press Bookstore.

		Fundamentals of Technology Project Management Master the specific project management issues that technology professionals must face. List Price $69.95 Now On Sale
		Managing Without Walls Optimize the effectiveness of your teams...no matter where they are. List Price $37.95 Now On Sale