CM009 | Content Management – Frame It! (Part 1)

Good grief. That was a bit rough. That discovery process was straight out of Dante’s Divine Comedy – the Ninth Circle of Hell, to be precise. But we made it through in one piece. Sort of.

For me, discovery is by far the most soul-destroying part of the process. It’s long-winded, it’s tedious, and it never seems to friggin end. Until it does, and then I find myself thinking about how badly I need to never, ever do that again. Until next time, of course.

On a happier note, completing the discovery process means we now have a far better idea of the kind of data we need to cater for and we can start forming a picture of the types of metadata we are likely to need. Let’s recap the final output from the last time we met:

This breakdown tells us we need to cater for three primary content categories, or, in SharePoint terminology, we need to cater for three distinct content types:

• Agreements;
• Finance Documents; and
• Personal Documents

When we assess the exact metadata requirements for these content types, we can identify and isolate specific metadata that is common to each, for example:

For agreements, we can assume we will need to know / track:

• The relevant organisational department (e.g. our company’s procurement department);
• The external party (i.e. the vendor name for a supplier contract, or the employee name for an employment contract);
• The type of contract (e.g. a sales agreement, employment contract, or an NDA);
• The contract date; and
• The contract duration (where necessary)

For financial transaction documents, we may need to track:

• The relevant organizational department;
• The vendor name;
• The document date;
• The financial period the document falls into; and
• The type of transaction document (e.g. invoice or statement)

Once we have a basic idea what metadata each content type is likely to need, we can start mapping it out like this:

Content Type	Metadata Field
Agreements	Department
Agreements	External Party
Agreements	Contract Type
Agreements	Contract Date
Agreements	Duration (Months)
Finance Documents	Department
Finance Documents	Vendor Name
Finance Documents	Document Date
Finance Documents	Financial Period
Finance Documents	Finance Document Type
Personal Documents	Department
Personal Documents	Individuals Name
Personal Documents	Document Date
Personal Documents	Personal Document Type

Looking through this metadata list, we can see a few columns that sound like we might be able to group them together, for instance:

• Contract Type, Finance Document Type, and Personal Document Type all refer to a type of document; and
• Contract Date and Document Date both refer to the effective date of the document in question

Since we don’t want to track a thousand different metadata fields in the final solution, we want to reduce the number of fields we need to create in the first place and a really good way to do that is by grouping columns together that essentially do the same job. So in this example, we can collapse all the different document type field names into a single document type field name. We can do the same thing with Contract Date and Document Date. Heck, even “External Party”, “Vendor”, and “Individuals Name” do a similar job. So if we collapse all those functionally similar metadata fields, we end up with something like this:

Content Type	Metadata Field	Cleaned Metadata Field
Agreements	Department	Department
Agreements	External Party	External Party
Agreements	Contract Type	Document Type
Agreements	Contract Date	Document Date
Agreements	Duration (Months)	Duration (Months)
Finance Documents	Department	Department
Finance Documents	Vendor Name	External Party
Finance Documents	Document Date	Document Date
Finance Documents	Financial Period	Financial Period
Finance Documents	Finance Document Type	Document Type
Personal Documents	Department	Department
Personal Documents	Individuals Name	External Party
Personal Documents	Document Date	Document Date
Personal Documents	Personal Document Type	Document Type

Now if we use our Excel magic to create a matrix, we end up with this:

Content Type	Department	Document Date	Document Type	Duration (Months)	External Party	Financial Period
Agreements	X	X	X	X	X
Finance Documents	X	X	X		X	X
Personal Document	X	X	X		X

How cool is that? We now have a matrix that shows us:

• What content types we need to cater for; as well as
• The metadata columns we need to create for the content types in our list.

This is the point where I usually start getting super excited because I can start to see a framework form in the back of my mind.

Given how exhausting the discovery process was, I think this is a great place to break for today. In the next instalment, we will cover precisely what a content type is in SharePoint and how we go about building the backbone to support our Content Framework.

Until next time, measure twice, cut once. Oh, and remember to floss.