A Case Study in Translating Business Needs Into SharePoint Information Architecture

I got a good comment on my post about the folder-less SharePoint paradigm, and I thought it would be a good opportunity to show how to translate business needs and content analysis into business requirements that can then be translated into an information architecture. I decided to speak with the commenter over the phone, and I asked him some simple questions.

1. Give me 2-3 examples of business critical documents you want into SharePoint.
2. Explain to me what the document is, how it’s used, and who is invested in the document.
3. After getting a description I probed for potential metadata to use in categorizing and grouping the information.

As you can see I’m not going to specify the site/navigation taxonomy. This would take more analysis so I confined the case studies to content types, metadata, and libraries or lists.

Use Case 1: Market Research Study

The first document we spoke about was a market research study the organization used to hone their product development. As we talked I extracted the following useful bits of information to help categorize the information.

• Large document from outside source (PPT, DOC, XLS, etc).
• Delivered on DVD.
• Used in internal presentations to convey business/product case.
  • Used by engineering for product architecture. Sections of the research study are reused/decomposed to develop product requirements.
  • Manufacturing, planning and commercial organization utilize the information to understand demand logistics requirements in the supply chain.
• The loop is closed by validation activities to consider whether “we accomplished customer goals” (value proposition).

Proposed IA

• Create a “Market Research Studies” document library underneath (possibly) a marketing or research site.
• Add a site content type entitled “Market Research Study”.
• Add the following metadata columns:
  • Process Step (Delivered, Engineering, Manufacturing, Customer Analysis)
  • Product Category (Pharmaceutical, Medical Device, etc)
  • Document Owner
• Due to the obvious workflow I would look into automating this inside SharePoint.

Use Case 2: Product Complaint

The next is a document submitted back to the organization by field agents concerning complaints on manufactured products. This site needs to be very simple to use with a minimalistic form to supply expedient submission of product complaints in the field.

• Submitted action report.
• Photos, text, output report are all included when recording complaints.
• Receive back product in question then run evaluations.
• Then get populated to corrective action system (LOB web application).
• Records management/compliance needed.

Proposed IA

• Create a “Product Complaints” site underneath (possibly) a manufacturing or production site.
• Create a list entitled “Submitted Complaints”.
  • To the complaints list add a content type entitled “Product Complaint”.
  • Add the following metadata:
    • Product Category (Pharmaceutical, Medical Device, etc)
    • Complaint ID (from the LOB web application for cross references)
• Add a “Complaint Photos” library
  • Add a content type entitled “Complaint Photo”
  • Add the following metadata:
    • Complaint ID (from the LOB web application for cross references)
• Turn on auditing on all document libraries and lists in this site.
• Possibly create a Data Form Web Part to rollup all data by Complaint ID.
• This also is a workflow candidate.

Conclusion

This is a very quick attempt at translating content into SharePoint information architecture. Obviously, further content analysis needs to be done, and a supporting site taxonomy is needed for this site collection. You can see how quickly a more robust architecture can help rolling up and tracking data for this organization. If you have any questions on how I translated any of this let me know in the comments.