After researching our options and discussing the benefits of each alternative, out team set out to start configuring the document content types for the system.

That puts us around Step 5 of our original outline:
That description assumed we would convert a lot of legacy documents--which still remains to be seen.  Our main goal aims at creating the best possible system to manage future documents.  To start, we created a document content type based on Document and named it Company Document.  This gives us total control over any document Content Type without modifying the OOB Document Content Type.  We then replaced the Content Type in the top-level Site Collection's document library with Company Document.

The top-level Site Collection's library will hold our document templates used by other Content Types.  So now we need to identify what metadata will apply to all Company Documents (if any) and add that to the Content Type as a Site Column.  We created a list called Records Retention Schedules (these are mandated for us by the State).  We added the schedules that pertained to our organization to the list then added a new Lookup site column to the Company Document Content Type.

Next, we created a Request content type and a child type called New Site Request.  Although most sites include this feature as a Custom List, we chose documents because of the integration with Outlook and the ability to create Document Workspaces that could help our administrators collaborate with new teams to develop their requirements.  The Request type inherits from Company Document which now has a Site Column called Retention Schedule.

By adding the New Site Request template to the Site Collection's document library and setting it as the template in the New Site Request Content Type, we can pre-select the Retention Schedule used for all New Site Requests.  Usually, lookups don't work too well in the bod y of Word documents because the Content Control displays the integer ID value of the target lookup object instead of the column specified (or the column shown in the DIP--Document Information Panel).  However, when setting a Lookup value in the template, new instances of documents based on that template will display the proper Lookup value in the document body.  In our case, we wanted to note the document retention schedule in the document control footer.

In addition, because we used a Lookup data type for the document retention schedule, users can drill down into the definition of that schedule.  By clicking the document in the library and selecting View Properties, the user can see the Retention Schedule identifier (e.g., S1-020).  This code links to the Retention Schedule record.  That record references the disposition method (by another Lookup column).  By clicking that, the user can see exactly what process to follow for record disposition (e.g., destroy with permission).

We now know that we will need to design the architecture of our system in two ways:  Information Architecture (how the Content Types and metadata work to organize information) and Storage Architecture (how the lists and libraries aid in managing workflow, security permissions, and reporting). 

I identified three models of Storage Architecture which I documented for an article appearing on EndUserSharePoint.com soon.  I'll address how these models come into play for Document Management in the next installment.