How does one know what one doesn't know? When evaluating what one knows, it is hard to know where to begin. The wise men say, "The more you know, the more you know you don't know." If one believes such commentary, what is known constitutes the tip of the proverbial iceberg. Databases have an easier time with such missing circumstances. If the rows of a database table are lacking referents, an outer join query filtering for NULLs might detail for you all the missing items. In developing and delivering projects, such a reference list for our minds to link to does not exist, for an outer join or anything else. Often, we do not know everything that needs to be done, particularly as a project starts. The difference between success and failure is not so much what one knows, but in how one handles the gaps between what is known now and what needs to be known before one finishes.
Particularly on projects that are breaking new ground, many things need to be discovered and overcome. Team members must embrace grappling with these unknowns, instead of presuming that undocumented issues simply don't exist. Heavy-handed, high ceremony methodologies encourage project teams to rely on information handed to them; but methodology or not, every member of a project team must apply critical thinking to the work they perform. The questions that lead a project on the road to failure are the questions left unasked. An organization may be lacking a metadata repository, but the existing database structures still imply specific business rules. It is an exaggeration to presume a missing repository or a missing repository entry equates to having no rules at all. Likewise, building new applications involves incorporating both business and IT needs that have already been explicitly documented as well as needs that may not already have been called out.
The distinction between rules in a repository and rules inside code is a matter of expression, like considering what is explicit versus implicit. Some truth always waits to be rooted out through investigation. Analysts may not ask every question, and subject matter experts may assume some things as obvious. It is not unusual for fairly significant items to be left unspoken. Even these experts often don't know what they know, all the time. Many times a project's success depends on key individuals tracking down issues and needs that are otherwise obscure, and bringing those new found items into the light of day. True professionals attack each task. They seek out holes; they look for ways to address or redress those openings and close them. Often these professionals are zealous to identify the unknowns before anyone else notices. It is a passion for them. Uncovering these needs is a matter of applying one's experiences and exercising critical judgments in a given situation. What things should be expected, but are missing? Is it okay for those specific things to be missing? If not addressed yet, how best might they be addressed?
Managers attempt to institutionalize some zealousness by implementing standards. Checklists may be engaged as well. But standards and checklists only go so far. And while of value, there is a cost to setting up standards and maintaining them. The overhead necessary for documentation encourages organizations to be frugal in the standards they employ. Documentation overkill does not help motivate people to bring a project through to success. Sadly, this passion to know, to find, to resolve, does not come out of a bottle, or a training manual, or a checklist. The fervor to find a means to success is more an attitude than it is any one specific action.