Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by gnat, Jim G., MichaelT, Glenn Nelson, Martijn Pieters Mar 4 '13 at 14:55

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Is this an internal project proposal or one for a client? –  VirtuosiMedia Oct 1 '10 at 4:28
    
In general, for a client. –  Incognito Oct 1 '10 at 11:51
add comment

5 Answers

up vote 5 down vote accepted

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
share|improve this answer
    
The link to the document is broken –  mclark1129 Aug 10 '11 at 17:55
    
Looks like they changed their website. I'll update the reference. –  Paddyslacker Aug 10 '11 at 20:04
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
That is an excellent resource. Thank you. –  Incognito Aug 10 '11 at 20:31
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
would you mind explaining about this in more detail - how and why does "endorsed article" answer the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Mar 4 '13 at 14:23
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.