Skip to Content

[X] CLOSE MENU

Fundamentals of AV Preservation - Chapter 3

Section 4: Drafting a Statement of Work

An SoW, as defined for the purpose of this text, is a document that provides context to help the reader understand the goals and intent of the project, followed by details of the scope, process, timeline, communication protocols, technical specifications, and a request for pricing. In larger organizations an SoW may make up one part of a request for proposal (RFP) that also includes legal and contractual information. In smaller organizations it may make up the heart of the RFP with few other components.

The process of drafting an SoW and issuing RFPs provides an opportunity to learn from others, ranging from organizations that have recent experience to share about performing similar work to vendors who are willing to engage and share their expertise and broad experience across a diverse customer base. This chapter will provide a framework, reference points, and a vocabulary that can be used to prompt conversation with others as you create an SoW. Before issuing your RFP, ask colleagues to review and critique it in order to help confirm and/or shape decisions. If the SoW will be used with a digitization lab that is internal to the client organization, meet with the digitization lab team throughout the SoW drafting process to seek feedback and input. If issuing an RFP for external service providers, the Q&A portion of the process can be a great point of reflection if vendors ask questions that point out unforeseen issues or identify gaps that may have been missed. The author of this chapter worked for a reformatting service provider serving archives between 1999 and 2006, created and taught a graduate level course on this topic for three years, has drafted over 25 SoWs for clients of AVPreserve since 2006, and has managed several of those projects through to completion. Even still, every new SoW and every new implementation brings new insights, lessons learned, and ways to improve and do better the next time. There is always more to learn and ways to continue improving, so use this document as a starting point, but also be sure to use the process as a platform for learning and refining.

There are a number of pieces of information that are important to convey in any SoW, for the sake of both the client and the vendor. The headings below may serve as an outline for an SoW or may simply serve as specific points that are incorporated into an SoW. The thoughts and considerations supporting each heading will provide the information needed to best decide how to incorporate these points into an SoW that is designed to serve a specific organization and set of circumstances. 

Before delving into the details below, it may be helpful to review the diagram in Chapter 3, Section 1 in order to gain perspective on what follows the vendor selection and pilot project phases of a larger project. This diagram illustrates how many of the items discussed below tie together within the larger process.

4.1 Sectons of a Statement of Work

About the Client and Project

Learn More

Brief Description

Learn More

Timeline

Learn More

Client Points of Contact

Learn More

Communication Protocol

Learn More

Learn More

Shipping

Learn More

Pilot Project

Learn More

Definitions

Learn More

Care, Handling, and Storage

Learn More

Reformatting

Learn More

Head and Tail Content

Learn More

Reference Files

Learn More

Directory Structure and File Naming

Learn More

Learn More

 

5 Tips for File Naming

  1. Beware of filename dependency
    Filenames are not actually part of the file but rather are part of the file system and are therefore not dependably persistent over time and across systems. Instead, the Unique ID (UID) assigned to the object should be the constant identifier used to track and maintain the provenance of the file. The UID may end up being the same as the filename, but regardless, be sure to embed the UID inside the file in an appropriate and documented place. 

  2. Do not overthink filenames
    Whether the filename is a randomly generated value or not, be systematic. Think, “Is this logical? Can I spell out the rules easily enough to do batch renaming?” In trying to create the perfectly contained and expressed filename or UID structure, there is a strong temptation to overthink to the point that they become non-systematic or too idiosyncratic to be logically parsed. If a naming structure is not systematic enough to have a piece of software perform a series of logical renaming steps, then manual renaming and retyping of filenames may be required at some point in the future. 

  3. Do not use filenames as database records
    Filenames are not the place to cram in a bunch of descriptive and structural information. That’s what databases are for! All we require from a filename and ID is that they act as a link to the database record for that unique object. Trying to cram excessive descriptive information into a filename creates unwieldy names and is often futile because of how often conditions or conventions change and new scenarios come up over time. Having filenames that are tied too closely to specific scenarios creates inflexible structures that require non-systematic revision when situations change, which creates the predicament described in tip #2. 

  4. Keep filenames machine-readable
    There is often an urge to make a file naming structure decodable by humans, but it also needs to be decodable by computers. Avoid characters that are not URL compatible, that require escape characters, or that are reserved by operating systems. Limit options to numbers, letters, periods, and underscores. 

  5. Consider existing filenames
    As noted above, the inherited filenaming structure of born-digital content may refer to complex file and directory structures that must be maintained in order to preserve the entire content. 

 

 

Metadata

Learn More

Learn More

Quality Assurance and Control

Learn More

Learn More

Learn More

Learn More

RFP Response

Learn More

 

Section 5: Post-Digitization >