1.0 Title: Transmittal
2.0 Purpose: To identify the contents of a physical or information delivery and its sender and receiver - along with any discrepancies in the actual versus the expected contents. It may also form the basis of "non-repudiation" of the document by either party, as well as forming the basis of a claim for payment.
3.0 Usage: There are different use cases and reasons for writing down a list of items and using it as a cover letter or as an attachment to a cover letter. It goes from an informal, practical self-reminder to a means of forcing an acknowledgement of receipt of one or more items - that may otherwise be hard to get. This acknowledgement can be an important dispute resolution mechanism - or even a trigger for other actions - such as "now pay me".
For hri07e projects the transmittal is both an electronic message and an inventory and status change notice to the receiver that an activity or milestone has been completed and now the next action is with the receiving party. (In football terms - this is the "punt").
4.0 Frequency: There should only be one transmittal for each transfer of deliverables - and it should only be issued once. If the delivery fails completely and the receiver claims they were never notified to expect something - that becomes a different problem that the receiver is not satisfied with the deliverables or if the deliverables are damaged or modified in some way during transit.
Consideration should be given for a timed response mechanism of some sort to avoid the first problem. For the second problem; duelling pistols are no longer legal so a host of other, less gratifying solutions are available. Those are out of scope for the transmittal however - although it can become a very important document in the resolution of the problems - especially if the quality or integrity of the transmittal itself is called into doubt.
5.0 References
5.1 transmittal should be used in conjunction with the km4 CDRL on hri07e projects.
6.0 Responsibility
Typically the person who "seals the envelope" is the one who must swear that whatever is on the list is in the package. (For the same reason that the customs agent asks you "did you pack you own luggage?")
At the other end the person who signs for the package gets blamed for anything missing - unless of course the package has an unbroken original seal - and the suspicion shifts to whoever opened it (typically the lowest paid, temporary worker who has no idea what is in the package.) This may be "sub-optimal" and should be considered at both ends.
Depending upon the value and sensitivity of the documents and deliverables in question - the transmittal may be just a temporary throw-away document - or it may have to be retained forever - with multiple signatures and and sign-offs.
For the more demanding requirements - the document ceases to be referred to as a "transmittal" and take on something more ominous - such as "payload" or "register" - and will be found in something other than project management circumstances.
7.0 Ownership
Transmittal are the property of the organization or person who generates them - plus the property of the org/person who receives them - which means there should be 2 (two) copies.
8.0 Effort
9.0 Risks
10.0 Contents
- receiver
- sender
- list of contents
There are a number of formats which have different sources or origin which can be used as "the list" - including things like Bills of Materials, Bills of Lading, Packing Lists, "Schedules", ISEL's, CDRL's and so on. If none of those exist then the transmittal itself can be used as a reference document - provided it isn't temporary.
- tracking information
- status information
- delivery instructions
- hash information
11.0 MetaData
12.0 File Handling Policy
13.0 Procedures
14.0 Tutorials