Question

When drafting a project proposal, do you use any standard template?

What features/information should be included? What is nice to have included? What sort of boiler plate information should I shove in?

Do you find any design pattern or concept particularly helpful?

Was it helpful?

Solution

Have you ever looked at the Volere Requirements Template?

While it contains a little too much detail for my taste, particularly for a proposal (it's better suited for detailed up front requirements specification), the section headings are a great checklist to make sure you've thought about all of the different moving parts before giving an estimate or creating a proposal document.

Here they are:

PROJECT DRIVERS

  1. The Purpose of the Product
  2. Client, Customer and other Stakeholders
  3. Users of the Product

PROJECT CONSTRAINTS

  1. Mandated Constraints
  2. Naming Conventions and Definitions
  3. Relevant Facts and Assumptions

FUNCTIONAL REQUIREMENTS

  1. The Scope of the Work
  2. The Scope of the Product
  3. Functional and Data Requirements

NON-FUNCTIONAL REQUIREMENTS

  1. Look and Feel Requirements
  2. Usability Requirements
  3. Performance Requirements
  4. Operational Requirements
  5. Maintainability and Portability Requirements
  6. Security Requirements
  7. Cultural and Political Requirements
  8. Legal Requirements

PROJECT ISSUES

  1. Open Issues
  2. Off-the-Shelf Solutions
  3. New Problems
  4. Tasks
  5. Cutover
  6. Risks
  7. Costs
  8. User Documentation and Training
  9. Waiting Room
  10. Ideas for Solutions

OTHER TIPS

Do I use a standard template? Yes

What features/info is included, nice to haves:

  • Cover Sheet
  • Meta Data: Customer Contact Info, Developer Contact Info, Project Name, Date
  • Customer Profile (optional, but good): Includes competitor info, products or services sold by the customer, current situation and objectives, target market, market position. The average small business cannot provide most of these.
  • Project Overview: Includes detail in outline format. This is where the project work is defined.
  • Not Included: Things specifically omitted from the project.
  • Initial Materials: A list of things needed from the customer to get started as well as the dates they are required.
  • Site Map: Optional, but good if you're doing a website or complex application. Nice graphic.
  • Demographics: Of the end-user, usually in the form of a nice graphic.
  • Creative Brief: Optional. This is for designers, and includes things like communication history, the message, personality and tone, audience (current mind set) and audience (resulting mind set), competitor websites, example websites or products favored by the customer, company colors, style guide (usually external). It documents existing materials such as logos, brochures, etc.
  • Project Timeline: A breakdown of when stuff should be done with final estimated completion date. My template has a big fat disclaimer that timelines depend heavily on customer participation.
  • Cost Breakdown: The cost of the different task to be performed. When possible, this section also includes a "return on investment" analysis.
  • Project Agreement: Payment terms, earnest money, 100% money back guarantee, single point of contact required, client supplied materials and approvals need to be timely, extra billing or time if the client changes the scope of work, hosting info (for websites), right to use the work for self-promotion, applicable laws, source code ownership statement, availability of software escrow, signatures.
  • About Us: Includes company info with photos, examples of our work, testimonials, other services offered, team profile with photos.
  • Conclusion: Thank you's and contact info.

Boiler plate: As much as possible. All of the above has something even if it's just filler text. This article was influential for me: http://articles.sitepoint.com/article/bulletproof-web-design-contract

My proposals usually come out to 14 to 20.

There are many different ways to do this.

Here's one I found that I would endorse - it has the freelancer approach, but really this is what you want to be doing:

http://tutorialblog.org/writing-a-project-proposal/

There are lots of guides online. The trick is to know which one will suit your needs. I taught a class in this stuff. My endorsed article really seems to be the essence of what customers want, and what should get you in the door.

This does NOT replace a project plan, which can be a more elaborate animal entirely.

When it comes to templates, I find the ReadySET templates to be pretty solid. These templates cover the major lifecycle points - project planning, requirements, design, implementation, testing, deployment/installation, support, and project finalization.

Something to keep in mind, though, is that templates should be modified to fit the project and processes. Very rarely can you just pull down a template from a book or the Internet and use it. I find templates most useful in determining what information I should have somewhere at each phase, and let the project determine how and where the information is captured.

The US Department of Defense put a lot of work into developing a full set of Data Item Descriptions (templates) to go with DOD-STD-2167A, and later for MIL-STD-498.

There's an old saying: "Navy Regulations are written in blood." If you read the DIDs carefully, you are likely to come away with the realization that every line of them is written in the blood of program managers whose projects died a horrible death because they neglected the item in that line.

You could do worse that look into these.

Licensed under: CC-BY-SA with attribution
scroll top