I’ve seen too many teams treat proposals and contracts as paperwork – something you rush through on the way to the “real work”. That attitude costs money. I’ve watched deals fall apart because someone skipped a step, or signed something they didn’t understand, or assumed the other side was on the same page.
So we wrote a procedure. Not because we’re a big company with a compliance department, but because we kept making the same mistakes.
You can grab the full document here: Proposals and Contracts Procedure
Here’s what it covers, in plain terms:
Who does what
The Business Development team finds the work. They collect RFPs, generate leads, do the initial requirements gathering, and keep the client relationship warm. The Project Manager writes the proposal and the estimate, then sends it up for review. The VP or CEO approves the pricing. Simple division of labour, but people still step on each other’s toes if it’s not written down.
The proposal itself
It needs to cover the technical stuff – what we’re building, what tools we’re using, the architecture. But just as important: the commercial stuff. Pricing for software licences, hardware, training, implementation support, travel. Payment terms. What’s excluded. Guarantee and AMC charges. Validity of the offer. Taxes.
The bit most people skip is the risk analysis. Before we commit, we do a feasibility study. Is this something we can actually deliver? Do we have the right skills? What’s the timeline looking like? If we don’t have templates or prior experience with the technology, we flag that too. Better to say no upfront than discover it six months in.
The contract
The VP prepares the contract based on inputs from the PM and BD team. It gets reviewed before it goes out. Both parties’ interests matter – if we’re being honest about risks, the client knows what they’re getting into, and we know what we’re signing up for. Internal risks we might choose not to put in the contract, but that’s a decision we make deliberately, not by accident.
After signing
The PM assembles the project team. During the engagement, the VP or PM collects client feedback at regular intervals. The core team analyses it and reports back. If there are changes, they go through a proper review – commercial impact, documentation updates, configuration management. Nothing happens in a vacuum.
Why this matters
The whole point of the procedure is that information flows in the right direction. The VP needs to understand what the PM is telling the client. The PM needs to understand the commercial constraints. The development team needs to know what was promised. When that chain breaks, projects go over budget, clients get surprised, and everyone loses trust.
The document is pretty dry. It’s a procedure, not a novel. But if you’re running a small team and you don’t have something like this, you’ll learn the hard way why it exists.