Early on during the Canadian Patrol Frigate (CPF) program I asked “where do I find that information?” and was presented with a line printer output about a foot thick that contained all of the officially defined reports and documents that were supposed to be delivered to the government of Canada under the contract. Each “deliverable” was identified by an alphanumeric label, a short title and some other data – like due date and the responsible work unit; not more than 3 lines with a space or two between each record. This report was referred to (oddly enough) as the “Contract Deliverable Requirements List” (or CDRL for short – pronounced “sea drill”) and was treated as though it had been delivered by angels from above.
Every single item in that report had its own specification for what it was supposed to contain, look like and accomplish and the specification itself was based on the US Department of Defence (DoD) MIL-STDs – with some minor exceptions. For example – part of the reliability team’s task was the “Failure Modes, Effects and Criticality Analysis (FMECA)” based on MIL-STD-1629a – and which was to be done for every mission critical system on the ship. (Since the determination of what was “mission critical” and what wasn’t was largely determined by the FMECA – that was a lot of stuff).
MIL-STD-1629a (and most other MIL-STD’s) has an appendix of “template” like documents that were referred to as “Data Item Descriptions” or “DIDs” – which described the elements of the FMECA – such as a “Functional Block Diagram”, a “FMECA worksheet” and a “Criticality Chart” (which was kind of cool because it showed how many frequent problems you had left that could kill people – hint: there weren’t supposed to be any.)
Since my original question was an attempt to make sure the information was available to those who needed it and would be up-to-date I wound up chasing my way through DID after DID to see who it was that decided what name tag was going to be dangled off a valve handle for instance, and who got to decide that theirs was the right tag and everyone else’s tag was wrong. Typically – several people got to decide – and they were all right – whether or not the tags were the same.
My thought early on was that this information needed to be “normalized” by the information system so that a valve only had one tag (which eventually happens onboard – because the sailors will do it if nobody else does) but more so that there weren’t nine other numbers existing in the files that gave the valve or whatever some other tag label. Also – while the tag number is connected to a physical object – the calculations that decided what flow that valve was supposed to handle was buried away where nobody would ever find it again - especially with a different numbering system.
My second thought was how many of the parameters that made up the ship were repeated over and over again and how many of the reports were redundant and generated extra work by continually having to be updated for their own internal calculations.
The solution; move to a new job because that situation wasn’t going to change.
Conclusion: The parameters that make up a engineering design or a businesses process should be identified, made available and rationalized so that they don’t get recreated over and over again.