When you get a request for proposal with a 20-page document submittal spec, you assume that everything is covered. I mean, you are being told exactly how and how high to jump. As long as you follow the spec, you’ve got it covered. You likely flip though the codes, and take exception at the code level and make a number of other judgments i.e. this isn’t available, that doesn’t apply, etc.
But in terms of a deliverable, there is a CRITICAL piece of information which RARELY gets communicated, and OFTEN causes problems later on. You need to know the answer to the following question…
How MANY documents are required for EACH CODE?
This single piece of information is one of the largest causes of disagreement (and rework) between suppliers and their customers. Let’s take a frank look at what really happens.
A recent problem clearly shows the concern… A Customer ordered 30 orifice plates and asked for “Datasheets”. There were 4 different process conditions so the supplier, being very information capable, assumed they would submit 4 datasheets, each with a list of all associated tags.
But the customer demanded 30 datasheets!
Their information system required a document for every tag. Not only more work, but arguments, possible disagreement and, of course, frustration followed.
In another situation, consider the supplier who had to submit 20 drawings. Of course, they assumed each drawing would be submitted individually.
But after being awarded the job, they were told they must package ALL drawings into a compilation (with Table of Contents, hyperlinks etc.) … PRIOR TO EVERY SUBMITTAL!
Guess what folks?
This kind of thing is all billable work! If you define upfront that you are supplying 20 documents, and your quote calls out that you submit documents individually, you have a standing to bill for the compilation work. While this is ideal, who actually takes the time to do this anyway?
DocBoss makes this easy but what if you are doing this work manually?
There are great Information Managers and great Information Systems out there. There are times when suppliers argue about doing “stuff” they really SHOULD be doing.
But there are terrible systems which require ridiculous volumes of “overwork”. You need to protect yourself against open-ended / undefined deliverables. You may still have to comply, but you should be paid to do the extra work.
Now maybe the exact NUMBER is a pain in the butt. Instead, define them by category. Simply write the following text beside each doc code.
– “By Tag” (like calibrations)
– “By Model” (like instrument drawings)
– “By Order” (like POs)
– “By Sub-supplier” (like quality manuals)
– “By Heat Number” (Like MTRs*)
– “By Skid” (like MTRs*)
– “By Drawing” (like MTRs*)
(*) it is very important to define the structure of MTR submissions. Doing so by Tag is valid too.
With those notes written beside each document code, you define your scope of work, you define how many docs you are going to handle, and how you are planning to package them. You don’t need DocBoss to start doing this.
Of course it’s great when the volume of work connects to how you charge for documentation services because you are charging for this work. Right?
Check out our article called How To Turn Document Control Into A Profit Center to learn more about the DocBoss Prices and Estimates feature…