Get enough information from client to start project

Question

I am trying to create a form that request for information from a prospective client, this form will have to work for all kinds of industry (business, construction, design, programming...).

In most cases you generally need for example:

• Company Background
• Overview
• Requirment
• Timeframe
• Budget

Yet people who submit this kind of forms only submit (even if you notify them to specify the information), example:

Overview: I need a website.

Is there a process I can take them to submit more relevant and enough information to give it to my team members and start the project ?

Answer 1

If you are talking about a project that has already been approved and is in the pipeline, then I defer to @Doug B's response.

However, if you are talking about a form that sits on your company's website, used by prospective clients to contact you because they are shopping for an agency to meet their needs, then there's a balance between asking for enough information to be useful to you and not asking so many questions that they get frustrated and move on (although they'd have to answer the questions anyway at some point in the project!).

It is becoming more common for agencies to provide a "Project Planning" document up front, rather than/in addition to the basic contact form that typically only receives the "I need a web site" responses. Smashing Magazine's "Web Design Questionnaires, Project Sheets and Work Sheets" article links to several in that arena; my favorite has always been the Happy Cog example, because in addition to eliciting important information, it sets the stage for the ways in which the client needs to be involved for the overall success of the project.

Answer 2

Based on your question I assume that the project has been approved by whatever level of authority is appropriate, and you are trying to give the project team a reasonable idea of the "big picture".

Generally speaking you want to document (in no particular order):

• The business case for the project. Why is the project important? How does it add value to the end user? What is the benefit for your company? What is in it for the team other than hard work & grief?
• A description of the project-level product. What are the component sub-products? Which sub-products are made by your team, and which are coming from outside of the project?
• A list of key team members. Who is the PM? Who is the project champion? Who is the customer? And probably most importantly - who is in charge?
• An idea of timescales. When is planning going to be completed? When do we start work? When does the product have to go to quality assurance? At what stages will the project plan be reviewed and revised in a controlled manner to reflect the reality on the ground?
• An idea of how this project will be better than previous ones. What were key problems/issues with similar projects in the past and how to avoid them? What did you do right in the past that you want to repeat?

I think this is about the minimum information that the entire team needs in order to build team spirit and feel like they are involved in something greater and better and more important than their functional unit.

Exactly what you include will depend on your target audience and the size/scale/criticality of the project. You should scale your documentation as appropriate. Most of my points below can be met with a couple of sentences or a hundred pages, your choice :-)

Answer 3

I'm not sure of the intent here - you want a form that a customer just fills out that gives enough information that a project team can just take and begin the project? And you want it to be cross-industry?

You're missing WAYYYYY too many steps here. You're missing the estimate, the planning, the charter, the stakeholder ID, just off the top of my head. It sounds like you're trying to remove the PM/Client interaction, which is a recipe for disaster.

One of the most often cited reasons for project failure is inadequate understanding of the project requirements up front. And that's for projects with a lot of face-to-face communication. Trying to reduce that to a form is only guaranteeing failure.

And that's not even tackling the issue of cross-industry.