The Standard Caution About Abstractions applies to this page.
Introduction
“TBD” is best used as a formal placeholder for information that is needed, but not known at the time a document is published1 . The idea makes it possible to abstractly describe things without getting stuck on the precise details of parameterization or evaluation.
“TBD” is also used informally to stand in for unknown topics and documentation being deferred from consideration or, sometimes, to inoculate an author from being held to blame for things they know should have been thought about before publication.
When used formally, the concept can take on several forms, all of which represent work yet to be done. With a little care, it can be used to support disciplined procurement of developmental services2. Because the acronym “TBD” itself is useful, the abstract notion is referred to here as “TBX”.
Asides
1. Although the following guidelines are phrased in terms of external procurement, their adaptation to internal handling of developmental should be self-evident. For example, I often made liberal use of TBX when drafting specifications, making a “to-do” list of parameters and evaluations that need to be accomplished in order to finish the requirements. The items on that list become the basis for assignments to subordinate or associated personnel.
2. It might prevent confusion to note that the use of TBX is distinct from the concept of surrogation. A TBX parameter might mature into a surrogate, and an established surrogate might use a TBX value until an acceptable value has been calculated, but the governing concepts and usages are completely different.
General Guidelines
1. The use of TBX in a Request for Proposal (RFP) should be explicitly authorized by Program Management, because it will impact Pricing Instructions (PI) and, often, the supplier SoW. Major elements of the solicitor’s Source Selection process will otherwise be uncoordinated, and their long-term objectives will be severely jeopardized.
2. Definitions of the various forms of TBX, including intended rules for resolution, should be explicit in the RFP and in the PI. It is rare, and typically counter-productive, for 100% of the technical issues to be resolved when an RFP is issued: in many cases, Configuration Identification, requirements parameterization (and, therefore, evaluation) cannot be definitized until an at-least conceptual design is agreed on. Proposal responses to the identified unresolved technical issues can (and often should) be used as discriminators. Such usage needs to be explicit in the selection criteria in order to avoid subsequent legal issues.
3. Instances of TBX should be serialized within each CI. It usually works best if all types of TBX are serialized in a single list, because the maturation process can cause both parameters and values to change the type of TBX representing them. Serialization provides for an explicit list of technical issues to be resolved. Therefore, status can be developed, which implies that “management control” of issue resolution might be feasible. Having a single list for each CI enables close-coordination of multiple documents relevant to one (or more) CI’s. Note that serialization within CI admits to the use of a single pointer in multi-lateral ICD‘s and ACA‘s, further supporting a technical-based integration of the parent project. This notion suggests3 that identification of TBX should probably be considered during Configuration Identification4.
4. Each instance of TBX should have a resolution milestone identified in the Deliverable Items List, typically associated with, but in advance of some specific project review. In most cases, TBX should be resolved no later than PDR. In many cases, it will be useful to explicitly recognize resolution activities in the supplier SoW.
5. Each TBX item should also have specific instructions for pricing, which might (or might not) include a specific value for technical parameter(s). Specific TBX values are useful when the solicitor recognizes that a final value is not available5, and wants to establish a level playing field. Instructions that direct the proposer to supply a value based on their ingenuity can result in useful discriminators between potential suppliers.
To Be Determined (TBD)
“TBD” means that the solicitor knows the information is important, but leaves it to the ingenuity of the supplier. Once the supplier provides it to the solicitor, the vendor will be held accountable for meeting it, which encourages the supplier to exercise all due caution. Each instance is associated with a resolution milestone (which might be as early as submittal of their proposal), but no pricing value is supplied in the PI.
Example: an RFP-draft specification might contain “…shall have an uninstalled weight of at most TBD32.” Item 32 of the TBX list notifies the proposer to provide their resolved value to the solicitor at least 30 days in advance of the PDR data package delivery, at which time it will be placed under formal Configuration Control by the solicitor6. For pricing purposes, the respondent is directed to apply their best in-house practice, and to provide rationale for the pricing estimate with the proposal, where that rationale includes a summary of the practice7.
Use of “TBD” maximizes the supplier’s opportunity for ingenuity, but provides the solicitor with an opportunity to make adjustments before things go too far. It is used when the supplier is not very sensitive to the resolved value, so the risk is low. Because it can be used as a discriminator8, the supplier is motivated to minimize impact on the solicitor’s program.
To Be Supplied (TBS)
“TBS” signifies that the solicitor will unilaterally determine the information and provide it to the supplier in the due course of time. Each instance has directions in the PI, relative to a resolution milestone (usually at or after program start).
Example: an Envelope Drawing might contain “…shall have a provisioned weight of at most TBS17.” Item 17 of the TBX list directs the prospective supplier to use 4852 lbf for pricing purposes, identifying 60 days prior to SRR (elsewhere scheduled) as the date by which the solicitor will supply a final value.
Note that, in this example, 4852 lbf is not a “requirement” in the normal sense of System Engineering. It simply places all prospective suppliers on a level playing field for source selection purposes. Furthermore, it may be that the final resolution could significantly perturb the suppliers plans at that time, and that they should reflect that possibility in their pricing strategy.
In the context of the example, it is interesting to observe that any pretense of 4852 lbf being a “firm requirement” will simply obscure the risk properly associated with the topic of weight. Obscuring risk during the procurement phase of a project is a significant source of cognitive bias down the road.
To Be Resolved (TBR)
“TBR” means that the solicitor knows an issue cannot be resolved unilaterally, and will consult with the supplier to work the issue early in the program.
Example: an RFP-draft specification might contain “…the installed weight shall be less than or equal to TBR126.” Item 126 of the TBX list directs the supplier to support resolution by way of a bilateral working group expected to complete at least 30 days prior to submittal of the SRR data package and, for pricing purposes, to apply best industry practice, identifying relevant industry standards with their proposal.
In the context of the example, the supplier is (of course!) aware that their schedule performance is contingent on that of the solicitor. The resolution represents (therefore) a shared risk, and should be addressed accordingly in their proposal.
Footnotes- In this context, “document” includes any form of release (e.g., book-form, sheet-form, data set, data base, analytical model, etc.).[↩]
- Without at least a little care, a real mess can be made.[↩]
- with malice aforethought[↩]
- This is the same as saying “we want a dingus that does this, and here’s a list of the known unknowns”.[↩]
- For whatever reason.[↩]
- And, therefore, subsequently external to the supplier’s change authority.[↩]
- Placing that rationale in the context of cost moves it to the proposal’s cost volume, which is not usually page-limited.[↩]
- Provided that the success criteria are written accordingly[↩]