Blog
Turnover packages with many sections: building the record as the job runs
The turnover package is the deliverable with the longest shadow. It arrives at the end of the job, it is…
Read NowWhere a submission specification calls for cover pages, each document goes out under a front sheet in the customer’s format, carrying data about the document underneath.
Layouts vary from customer to customer. The data they want on them is largely the same. The tags the document belongs to, the document numbers, of which there can be several: yours, the customer’s, sometimes the end user’s and a sub-supplier’s as well. The document code and title, the revision, the issue purpose. And, where the format asks for it, the revision history: a block showing each time this document was submitted, the submittal date, the revision number, the issue description, who prepared, checked and approved it, and the status it came back with.
It is frequently not one page. Customers specify cover sheets running to three or more, with different data on each: the revision history on the first, the equipment list on the second, document data on the third. Every page has to be right for every document on every submittal.
The history block is there for the reviewer. Someone opening revision C sees on the first page that revision A went for approval, came back with comments, and that revision B answered them. The document carries its own record of where it has been.
It is also what makes cover pages expensive by hand. A cover page without history can be templated once and reused. Add the history and every cover page is different, because each submittal puts another line on it. On a submittal of a hundred documents that is a hundred cover pages to build, and every resubmittal sends you back into them one at a time to update the history.
The data is already there. The tags sit on the equipment list, the numbers and codes on the document list, the history in the record of what was sent. Pulled from that data as the document is submitted, the cover page is an output rather than a file anyone maintains.
DocBoss builds them from that data. Every document is linked to its equipment, so tag data is inherited rather than typed. The customer’s format is loaded as a template and defaulted onto their projects. The cover page is produced per document, per issue, and the history on it includes the previous and current submission data. The same data feeds the supplier document index, which shows the full history of every document and can be produced in the customer’s layout or in your own, on demand or on a schedule. Where the deliverable itself has to be a spreadsheet, whether that is the index, a spare parts list or a data sheet, the cover page can go inside the file as a worksheet, built from its own template.
Cover page requirements are not getting lighter. The data they call for is already in the project, and it can populate any layout the customer specifies.
