To develop a workflow and timeline, think through each stage of creating and using your archive:
Finding and acquiring source material
Processing or cleaning content and putting it in a consistent format or file type
Storing your material somewhere accessible
Structuring your content so that it can be processed by computer programs
Developing an interface for your material and sharing it
Depending on the original format of your content and how you want to use it at the end, these steps might come in a different order. Try developing a sample workflow to move through these stages, then look for the tools or resources you would need to carry it out. Does that workflow seem feasible?
A sample workflow might look something like this:
Workflow for creating a simple archive of historic buildings in your town to be used for tours
Make list of buildings to include.
Create a database table using a number for the primary key. Create fields for other data:building name, date of construction, architect, latitude, longitude, building type, link to folder with photos of the buildings.
Take photos of each building from each side, and a close up of the entrance.
Edit each photo for consistent size and lighting, save in consistent format with descriptive names.
Use Google Maps to find the latitude and longitude of each building, enter into database.
Go to town archives to look up architects and dates of construction, enter into database.
Create list of building types based on a controlled vocabulary and apply one type to each building.
Create a wireframe for the website where people will explore the map.
Make the interactive map using content from the table.
Build beta version of the website and embed the map in the website.
Add search functionality.
Test site on computers and mobile devices.
Share and publicize site through newsletter and posting on sites x, y, and z.
In this workflow, you would go back and forth among steps like acquiring content, structuring it, and storing it multiple times. This is common in an archives project, especially when the materials do not already exist as a physical archive in a similar structure. This workflow also makes it clear how a step that doesn’t take very long for one entry can add up quickly if you have hundreds or thousands of records.
The steps of writing out your workflow will probably raise some questions for you about acquiring content, finding tools to make your process flow better, and structuring your data. In the example above, you might realize that you want historic photos to accompany the images you take yourself, so you might add in a step to check with the town archive or to look on Wikimedia for public domain photos of the buildings. You might decide that you want to meet with your programmer earlier in the process to make sure you are saving your data in a format that works for your site.
When you have a sample workflow, start listing the tools or resources you will need for each step, and the expertise or additional labor you might need. The original workflow draft helped you explain what you will do in each step; this amended workflow tells you how to accomplish it. For the example above, you would want to figure out where you would get the list of buildings to include, what camera you would use and whether you would need a tripod, whether you wanted to use Gimp or Photoshop for editing the images, and what software you needed for creating the database and website. These choices, in turn, will help you identify whether you have the needed skills already, or whether you might need to hire a photographer, database programmer, or archivist to help.
This workflow development is a sort of mental prototype that can help you avoid problems, but you will still want to do a real test run by following the instructions in the Prototyping or Wireframing section. In an archival project, the mistakes that take the most effort to fix are usually ones at the structural level: incorrectly dividing up data into individual fields, storing your data (especially media) in the wrong format, or deciding later that you need information that you left out at the beginning. This can often be avoided by being very explicit about your workflow and doing a good test runthrough. The prototyping and wireframing process, in which you work backward from how you want your end user (even if it’s you!) to use your content, can also help.
The workflow and trial runs will also help you make reasonable estimates on timing. The easiest way to get started is to try any steps that you can do in part, like digitizing, cleaning, and formatting the content for one record, which you may have already done as part of developing your workflow. While you may get faster at the steps as you work, you will probably also have to contend with unexpected problems like equipment failure, archival closures, or software bugs, so estimating time for the content collection and formatting as [the time it takes to process one record] times [the number of records] and then adding an additional 10% or so is probably reasonable.
Add in some extra time if you will be training someone else to do this work, or if you will be working off and on on this project, as those factors tend to lead to additional errors and require extra time for getting familiar with the process again.
For other parts of the process that can’t be tested out in this way, the most accurate way to figure out a time estimate is to take your wireframe model and talk to people who have built similar projects, ideally someone who will be working on your project directly. If you will be building the project yourself, you can still look for similar projects and contact their developers, or even look for online message boards or help forums related to your tool and ask there.
Overall, there are some important things to keep in mind that can help you minimize the time needed to develop an archives project:
The less customization you have, the faster you will be able to build the project. This is true both for the structure of your database or other data formatting structure, and for the website or interface you use to interact with your content. Remember that customization requires additional time for testing and review, not just for building the changes. It also tends to take longer to solve problems on a custom website or database because there won’t be as many people available to help in online forums or help sites.
Projects where the source content is consistent in format will go faster. The more varied your data is in content structure or original format, the more different workflows you will need and the more time you will need to spend on decisions that only affect a part of your content. This can be a good way to decide how to break material up into phases: work on all material with a similar structure at once, and consider breaking your project up into phases based on the types of material and its starting format.
The more time in a row you can devote to the project, the faster it will go. This is obvious from a calendrical point of view, but the total time spent on the project will also tend to be lower when you work on it without distraction. Breaks in your work make it harder to pick up where you left off, and make it more likely that you will need to renew product licenses, deal with program updates that change your workflow, or even find entirely new tools. Good documentation will help with this!
Look for parts of your project that can be run in parallel. Can you hire someone to work on one part of your project while you work on another? Can you have your computer batch processing images overnight so you aren’t waiting for that during your work time?
Continue reading: Tools & Resources for an Archival Project