Tender · week one
Sam and Tom pull out every information requirement, wherever it's hiding, and check every document the tender refers to. Anything missing, Sam asks the client for, in writing.
Sam's journey · Winning the work (tender) · Lesson 1
The client's wish list
Before you start
In the story
We promised to comply with two documents we'd never seen.
Back to the story
The right way
Bid submitted
Whatever isn't answered by the deadline goes into the bid as a stated assumption.
DesignDesign: Week nine…
On the job
The client asks for 4D. Sam points to the assumption, and it becomes a priced change, not a free gift. The client grumbles. Tom wins.
Skimmed by FridayTwo documents nobody had, promised anyway, and 4D for free.
Read, asked, assumedEvery requirement found, the gaps asked about, and the rest stated in the bid.
Think like Sam
Treat every "see Appendix…" and every document the tender mentions as a requirement until proven otherwise. Can you trace each one to a line on your list, and does every gap have either an answer from the client or an assumption in the bid?
Continue Sam's journey
Story 2: Whose system is it anyway?
The client has a Common Data Environment (CDE), an asset system and an inspection app for site. So do we. Nobody mapped which talks to which.
The right way, explained
The client's wish list is the order for the whole town. Before anyone builds a road, someone has to read the order. All of it, including the bit stapled to the back and the catalogue it points to.
If you're the client
Put every document you refer to in the tender pack, or don't refer to it. If you want 4D, say so plainly, and say what you'll use it for.
In the town See it in the town: Client Town places an order. What's in it?
Sam's view: Client Town places the order. Everything on our parts list should trace back to it.
Show:
The need, turned into a plan. Who makes what, and by when.
These are the Exchange Information Requirements!
The order: what the client needs from you, when, and what for.
For the audit What the auditor will ask
- Show me how you found the client's information requirements at tender, including the documents they referred to.
- Where did you raise gaps, and what assumptions went into the bid?
For the audit What good evidence looks like
- A requirements list, each line traced to where it came from.
- A log of the questions asked and the client's answers.
- Assumptions and exclusions stated in the bid.
ISO 19650 What the client should give you at tender
ISO 19650 expects the client to send a tender pack that tells bidders what information they need and how it must be produced. In practice it's spread across the documents, so you go looking.
| Look for | In plain words |
|---|---|
| The information requirements | What they need from us, when, and what they'll use it for |
| Their information standard | How things must be named, classified and formatted |
| Their methods and procedures | How information must be made, checked and shared |
| Reference information | Existing surveys, records and anything else they're giving us to work from |
| Key dates | When information is due: the delivery milestones |
| Security requirements | If the asset is sensitive, how information must be protected. If there are some, the bid has to answer them |
| The information protocol | The contract terms about information: who owns it, who can use it, and for what |
| How the bid will be scored | What the client will mark you on, so you know where the effort goes |
| Anything they refer to | Other standards and documents. If it's referred to and you haven't got it, ask |
Based on the ISO 19650 series: the ideas come from the standard; the plain-English wording, examples and advice are InfoTown's. ISO 19650 is © ISO and BSI. You'll hear the same language across the industry. Read more for free in the Information Management Initiative (IMI) Framework guidance from BSI and nima. For the full requirements, use the standard itself.