IAPM International Association of Project Managers

You are here:  News & Events » IAPM Blog

How To Prepare A Project Proposal

How To Prepare A Project Proposal 16.10.2014 - There’s been an empty lot round the corner from my home for some time now. It’s got hoarding up but frankly it’s an eyesore. The delay to putting up the new houses, I found out last week, is that the proposals from the builders have been rejected. Now it seems like we’ll be waiting for the local authorities to review a new proposal and maybe that one will get the green light.
The builders would have prepared a project proposal for consideration, and this is the document that also kicks off other projects. Sometimes you’ll join a project when the proposal has already been written and approved, and other times you’ll get involved right at the beginning when the sponsor is preparing the proposal. If this happens, you’ll probably get roped in to helping write the proposal, as many sponsors don’t have the time (or, dare I say it) the skills to produce a project document that will make sense to the decision makers. So here’s our guide to writing a project proposal.

What To Include

Background: This is a short section that sets out why the project is required. Provide some detail about the problem that the project is trying to fix and explain what’s happened up to this point that makes this project essential.

Requirements: You can make a bullet point list of requirements in this section. At the moment they can be relatively high level so things like ‘Improve customer satisfaction by 10% would be OK.

Proposed Solution: As you’ve probably guessed, this is the section where you document what your project is going to do! Set out the way you will resolve the problem by delivering this project.

Rejected Solutions: It’s also a good idea to include a couple of the solutions you considered but then rejected. This shows that you have done a thorough analysis and considered all the available options before coming up with your recommended solution to this business problem.

Deliverables: In this section describe the major deliverables. These are things that don’t exist now but that will exist after your project finishes. For example, new software, user manuals for the software, a new building, a new product or process. Break it down so that there are 8 to 10 items in the list. Some of these could be related to managing the project, such as testing documentation or quality control audit reports.

Timeframe: Here is where you set out how long you think the project will take. At this stage it is unlikely that you’ll have created a full project schedule, but you can probably estimate roughly to give the project stakeholders some idea of the project’s duration. If there are any fixed constraints that you have to meet you can also include them here. For example, if the project has to be completed by the end of the financial year or in time for a particular event, mention it here. A Christmas staff party has to be completed by Christmas!
You could also find that your project sponsor has promised the completed product to a customer by a certain date without having gone through the proper planning process, so you could be working to that sort of constraint as well.

Resources: List the resources you will need. This should cover everything, including people. At this point it is better not to include definite resource names but instead document the type of person you need, like a contract engineer or an HTML software designer. If you do have an idea of the exact person who could be brought on to the project team then you could mention them but don’t assume you will be definitely allocated this person.
Most projects will need other sorts of resources as well as people. Anything from computer equipment to building machinery or factory kit should be listed here. Of course, the list might grow as you define and plan the project, but write down everything you know about at the moment.

Budget: Add up the cost of your resources including the people and record this as your estimated project budget. This is another area of your proposal that may change as the project is fully planned, but at the moment you can at least include your best estimate.

Responsibilities: If you know who is going to be responsible for what, record it in this section. You will probably know that you will be the project manager (as you have been asked to work on this document) and who will be the project sponsor.

Reporting Approach: People approving projects like to know that there is some formal structure for reporting and governance as it shows the project is being managed professionally and there is less chance for something to go wrong. Set out here what you will be doing in terms of project reports. A fortnightly or monthly report to a Project Board is probably the minimum but your company or Project Management Office (PMO) might require other reports as well so list them in the proposal.

Project Governance: Governance is really about making sure that there is a structure in place to keep the project on track. Your governance approach provides oversight and ensures the project team act sensibly with an eye on the big picture. Your Project Board provides governance, so write about that here including who you expect to sit on it. You could also mention the PMO and any other processes in your company that ensure good governance.

Risks And Issues: List the major risks and issues that have been identified already, along with who is managing them and what you expect to do about them. Keep this list relatively short. If you want to, you can provide a link to your risk management software so that anyone reading it can see the full list of risks and issues online.

Success Criteria: Finally, it’s worth explaining how you’ll know if the project was successful. Set out some success criteria, such as ‘customer satisfaction increased by 10%’ or ‘software completed on time with fewer than 20 bugs’. You can always change these later but it’s useful for the whole team to know what they are aiming for and how success will be judged.

So that’s it – everything you need to put in a project proposal. You can download our project proposal template here to save yourself some time. If it turns out to be a long document you could also include a short executive summary. Some people will only read that, so make it good! Now your proposal is ready to submit and all you have to do is wait to find out if your project has been approved. Good luck!

About the author
Jason Westland is CEO of ProjectManager.com, an online project management software company. He’s also the author of The Project Management Life Cycle.

« Back to overview
IAPM Partners