Formalities and steps when getting from an initial contact to a contract (and templates of documents used during these steps)

Question

I have actually been looking for information on how to do consulting work (software development) as a small business. In this case I would be the sole owner of a company (or a sole proprietor).

What is a bit of a mystery for me are the formal processes in getting from an initial quote (that a potential customer may request from me) to a contract.

Are there many different documents that a consulting company should be prepared to send to a potential client, before a contract is signed? Is there a "typical" set of steps taken when negotiating with a customer from initial contact to a contract?

If so, what are the steps and the documents used during these steps? Are there any formal documents (excluding documents that are not part of the deliverable, such as Release Documents, and documents that are specific to the laws of the country) that a business should be prepared to provide to customer after a contract has been signed?

What could be good ways to find samples of (or templates for) such documents?

Answer 1

There is a "typical" set of steps that takes place, but this vague framework varies quite significantly in duration and content depending on project complexity, scale and negotiation duration.

The basics are as follows:

The client requests a proposal. This request may be made (1) publicly, or (2) to a group of companies or (3) to one company in particular. A company in this context also may be an individual person offering a service. This request will consist of a description of the job to be performed and varies wildly in length, from a few sentences to pages.

The company (aka contractor) responds by submitting a proposal describing how the job will be done. The company may ask questions about specific details of the project if they need more information. It may be necessary for the contractor to sign a Non-disclosure agreement (NDA) in order to get the information they need. There may be a back and forth for a while between the client and contractor. This stage allows for the client to asses the contractor and for the contractor to asses the client. The proposal may contain a cost estimate.

At this point, it's a good idea to establish a scope for the project, which is a definition of exactly what the final deliverable consists of (and what it does not consist of!)

The client will ask for a quote if they like the contractor and want to move ahead. If they do, the contractor sends through a formal quote, detailing exact amounts to be paid and when.

The client decides if they're okay with the quote. Once again, negotiation may occur over the price of various services and milestones. The scope may be revised to make things cheaper (and re-quoted). If they're okay, the contractor issues an invoice for the first installment. This invoice is what the client needs to pay for the work to start

The client may send through a contract to the contractor detailing the legal responsibilities of each party. This in turn may consist of several stages of negotiation in order to reach an agreement over the contents of the contract. Both parties sign.

Once the client pays the invoice, the contractor issues a receipt to the client, confirming the receipt of payment. The work begins.

At this point, the documentation supplied is dependant on the scope and what documentation was agreed upon as a deliverable.

That is a vague summary of the business transaction process. Since there is a lot of negotiation about price and scope and NDAs, it can vary in duration from hours to weeks. It may be as simple as a client emailing a contractor about a small website change or as complex as a government municipality subcontracting the design and construction of a new stadium.

TL;DR:

(1) Request for proposal: Description of job from client.
(2) Proposal: Description of how the job will be done from contractor.
(3) Estimate: Estimate project cost.
(4) NDA: Non-disclosure agreement ensuring contractor doesn't give client's IP away.
(5) Scope: Description of work to be done (and what's not being done).
(6) Quote: Actual amount to be paid at each stage and terms of payment.
(7) Contract: Legal document detailing responsibilities of each party.
(8) Invoice: Current amount to be paid to the contractor.
(9) Receipt: Confirms that payment was received for a particular invoice.

Answer 2

I've worked as a software consultant for more than 20 years, both as an independent and for a "firm", in the United States. To the best of my knowledge, there are no "typical" set of steps - things differ greatly depending on the project involved, the requirements of the customer, and the disposition of the consulting firm.

More importantly, your question implies that there would be a lot of effort involved before the contract is signed. In my experience, this is a flawed approach.

Programmers often think that we need to fully define the software to be built before the contact can be established. But this is not necessarily true. The approach I use is to discuss the project with the client, and then draw up a contract for a project that would define and document the software. So there isn't any "document" or "step" in between the initial conversation and the contract.

This first project then involves me identifying the "requirements" of the system. This work product is a document that establishes enough detail about the project that I would feel comfortable bidding on it. It also helps define the scope - things that aren't mentioned in the document are considered out of scope. Also, I am getting paid for my effort. This type of work shouldn't be done for free, as it will take a significant amount of time and effort, and the risk of not getting any reward for it is high. (Meaning: you could put all that effort in, and then the project never happens.)

This process is also advantageous to the client. They can use this document to request bids from other developers if they want. (I use this as a selling point, but no one ever actually takes me up on it.)

I'm not sure what you are getting at on the last part of your question - formal documents to be provided to the client after the contract has been signed. There are no formal documents that I provide afterward, except documents as identified as deliverables. So - a requirements document, or system documentation, etc.

Occasionally I have considered creating a "project completion questionnaire" for gathering feedback about how I could improve my service, but that wouldn't be anything "formal" at any rate.

Answer 3

What is a bit of a mystery for me are the formal processes in getting from an initial quote (that a potential customer may request from me) to a contract.

Ideally keep the steps as simple as possible to minimise the overhead and concentrate on what you do best. Instead of going from an initial quote to a contract, the quote and contract can all be rolled into a proposal. The following documents should be sufficient for most projects:

1. a standard project brief form to gather key information sufficient for you to write a proposal

2. a proposal template including standard terms and conditions for the type of work you do

3. initial invoice (assuming an up-front fee is required to start the project), final invoice

For simple or well defined projects, the project brief form may not be required at all.

Terms and conditions should probably include payment terms. Terms and conditions can be adjusted if and when there are any special circumstances.

Examples of standard terms and conditions for consulting work can be found on http://docracy.com or similar websites although you should probably hire a legal professional to check suitability for your particular circumstances.

Are there any formal documents (excluding documents that are not part of the deliverable, such as Release Documents, and documents that are specific to the laws of the country) that a business should be prepared to provide to customer after a contract has been signed?

Apart from the final invoice and maybe a receipt, software licences, login credentials and maybe some documentation, I'm not aware of anything else that would usually be needed.