One of our previous blog posts briefly touched on using up-to-date specifications and process documents to control data quality. For my first blog post, I’d like to spend some more time talking about these two documents. During my time with SSP, I have found the Spec Doc and the Process Document to be the cornerstones of any successful data-related project. Regardless of a project’s size or duration, having these documents in place helps to ensure that information is consistently and accurately being added to the GIS.

The Spec Doc

The Spec Doc we use is a comprehensive spreadsheet that includes each mapped feature (as its own tab), as well as any related tables that should be updated. These tabs then contain a list of all of the attribute fields associated with that feature or table, along with information about when an attribute is required, how it should be populated, and where to find the information needed to populate it. There is also a section that lists the rules for the graphic placement of the feature and another section for any miscellaneous rules that should be noted. For example, the graphics placement rules would describe required offsets, feature rotations, or acceptable overstrikes, while the miscellaneous rules would describe any assumptions that can be made when there is missing information.

Although the creation of the Spec Doc is a somewhat tedious process, it is extremely beneficial. By going through the entire dataset, feature by feature and table by table, all stakeholders are able to agree on what data is being captured and how it should look in the GIS. In addition, this process may help identify gaps that exist in the data or challenges that may arise during the project. By finding these potential snags early on, the missing information can be located, or a set of assumptions can be agreed upon – both of which can help to keep the project on track.

The Process Document

As its name suggests, the Process Document describes the actual process that is used to enter data into the GIS. It can be formatted as either a Step-by-Step or a Feature Placement document. A Step-by-Step document explains the entire mapping process, from start to finish, of how information should be added to the GIS. This format is useful for data projects that require editors to complete a series of ordered steps to map the data, like those used during work order posting. A Feature Placement document, on the other hand, is more of a general workflow of how each feature type should be added to the GIS. This format is more applicable to projects that do not require the data to be mapped in a particular order, such as a fiber data conversion project.

There are differing opinions on the appropriate length for a Process Document. Some people say that it should be a short document that is more inviting to use, while others think it should be a tome that includes every possible mapping scenario. It is my personal opinion that the organization and searchability of the document is more important than its length; an editor should be able to quickly find the information they need. Furthermore, it should include relevant examples of mapping scenarios the editors will encounter, how they should handle situations where there may be more than one correct answer and a few more unique mapping situations. These examples show editors the proper method for interpreting and mapping the data.

To use a baking analogy, the Spec Doc and the Process Document are a GIS recipe for success; the Spec Doc is the list of ingredients being used and the Process Document is the mixing and handling instructions – one doesn’t work quite so well without the other. And, like any recipe, they should both be actively maintained. The Spec Doc, in particular, should be treated as a living document that records the life of a project; every time an attribute is added, removed, or a rule is changed, it should be captured in the Spec Doc. The date of these changes should also be recorded to help reduce any potential confusion as to when they were implemented. Maintaining the Spec Doc not only helps to ensure that editors are accurately capturing the data, but also may help to control the length of the Process Document; instead of describing all of the ways the data should be captured, it can simply say, “refer to the Spec Doc.”

When used in concert, the Spec Doc and the Process Document are a match made in data conversion heaven. They both are used to define and streamline the preferred approach editors should use to add data to the GIS; this eliminates questions and ensures consistency. The Spec Doc and the Process Document are also great tools for large projects, especially ones that may require a rotating staff. Irrespective of who trains an editor, the documents provide them with the same basic tenets and expectations of the project. Similarly, the Spec Doc and the Process Document are perfect for projects that may have lengthy lull periods as they help to eliminate the time editors spend trying to recall how they mapped or attributed something previously.

Finally, the pairing of the Spec Doc and the Process Document are great assets to the QA/QC portion of any project. When all editors are provided with the same set of rules, it helps to clearly state the expectations for mapping the data and, as previously stated, to eliminate mapping inconsistencies. This, in turn, helps to reduce the amount of time initially spent QA-ing work and making corrections. As Edward Deming said, “Uncontrolled variation is the enemy of quality.”