8. The Challenge
Business
Process
Automation
Portals Social Co-Authoring
External
Collaboration
Workflow
Team
Collaboration
Incident
Management
Project
Management
Knowledge
Management
Enterprise
Content
Management
Application
Platform
18. Interviewer
• Solicit enough information
• Elicit more input
• Put some people on the spot to
talk about what they do
thornleyfallis.com
19. Interpreter
• Assimilate what is laid out for
you by your constituents
• Context is probably foreign to
you
• Verify you heard everything
correctly
• Communicate needs accurately
to any other developers
umassmed.edu
20. Therapist
• Likely not the first time some
technical person has tried to
help
• Bad experiences in the past
• Let them articulate their
frustrations
• Encouragement to keep the
ideas coming
wisegeek.com
21. Architect
• Master artist
• Problems are in your hands
• Designing something in
SharePoint to fit stuff that
wasn’t designed for SharePoint
• Built to last
careerbear.com
22. Gamer
• Multiple routes to reach the
same goal
• Get everything to fit into a new
site properly, especially during a
migration
gamersagainstbigotry.org
29. Content Architecture
1. The specification for a content management
solution
2. A set of activities and outputs for effective
content management
– Cleve Gibbon
54. Terminology
Not OK OK
Site Collections Sites
Libraries Folders, Buckets, Containers
Content Types Different kinds of documents
Columns Fields, Metadata
Lookups, Term Sets Choices
Document Sets Binders
Workflows Processes, Flows
Lists Tables
Web Parts Modules
56. Discussing Needs
• How do you think about your stuff?
• How do you group your stuff together?
• By who works on it?
• By what it applies to?
• By fiscal quarter?
• What do you need to know about your stuff?
• Where is this in the process?
• Who wrote this?
• What customer does this apply to?
• What works well today?
• What is broken?
• What would make your job easier?
63. WWW.COLLAB365.EVENTS
Translating into Requirements
What you might hear
“We work a lot
with other teams.”
What you might think about
• Which team needs access to
what and when do they need it
• Is this ongoing or temporary
• What process are involved here
64. WWW.COLLAB365.EVENTS
Translating into Requirements
What you might hear
“Sometimes we work
with people outside
the company.”
What you might think about
• In SharePoint Online, the ability
to grant external access is
enabled or disabled at the site
collection level
• You may be looking at a
separate web application or
farm outside the firewall
65. WWW.COLLAB365.EVENTS
Translating into Requirements
What you might hear
“We have a lot of different
groups of people that
need access.”
What you might think about
• If they’ll be Active Directory
Groups or if they’ll need to be
SharePoint Groups
• SharePoint Groups are visible to
all site administrators within the
entire site collection
66. WWW.COLLAB365.EVENTS
Translating into Requirements
What you might hear
“We work on a lot of projects.”
What you might think about
• Do the projects consist of just
documents or are there tasks,
calendars…
• Separate sites for each project
• Document sets for each project
67. Project Sets Option
PMO Team
Site
Active
Projects
Project C
Archived
Projects
Project B
Project A
Project Z
Project Y
Project X
68. WWW.COLLAB365.EVENTS
Project Sets Option
Documents are grouped together in a
‘binder’ for each project
• Can be treated as a single package
• Can simplify metadata by inheriting
• Different security can be applied to
each set
• Cannot allow external users access
• The package itself becomes the
record of the project
• Easier to roll up/consolidate project
information such as
• Dashboard of status
• Show all project plans
69. Project Sites Option
PMO Team
Site
Project C
Site
Project B
Site
Project A
Site
Project
Documents
Project
Calendar
Project
Issues
Project
Tasks
Project
Links
Project List
70. WWW.COLLAB365.EVENTS
Sites Option
Documents live in a separate area
altogether for each project
• Can have other project content
live alongside such as task lists,
wikis, etc.
• Different security can be applied
to each site
• Can allow external users access
• Need to maintain separate
listing/record of projects and
related info
• Harder to roll up information
about all projects
71. WWW.COLLAB365.EVENTS
SharePoint Building Blocks
Your Data & Attributes
Content Types
Site Columns
List Columns
Term Store
Content Type Hub
Compliance Center
…
Your Containers
Lists/Libraries
Sites
Site Collections
Content Databases
Web Applications
Farms
…
72. WWW.COLLAB365.EVENTS
SharePoint Building Blocks
Content Types
• Use to…
• Maintain consistency across
libraries and lists
• Isolate workflow, policies, and
other settings
• Information Management
(Records Management)
• Etc.
Site Columns/List Columns
• Use to…
• Drive views
• Expose via search
• Drive reports
• Preserve information
• Trigger workflow
• Etc.
73. SharePoint Building Blocks
Farm
Web
Application
Content
Database
Site
Collection
Site List/Library
Item
Item
Site
Collection
Site List/Library Item
Site List/Library Item
Content
Database
Site
Collection
Site List/Library Item
Web
Application
Content
Database
Site
Collection
Site
List/Library
Item
Item
List/Library ItemSite
Collection
Site
74. Taxonomy/Context – Uses
• Leverage security (List, Site)
• Differentiate list-based workflows (List)
• Segregate content (List, Site, Site Collection)
• Facilitate geographic placement (Farm)
• Control versioning (List)
• Account for alternate authentication method(s) (Web Application)
• Account for encryption (Web Application)
• Etc.
75. Taxonomy/Context – Considerations
• The content that will be stored as items
• The site and list/library columns that will identify, qualify, and differentiate those
items from each other
• The content types that will help maintain appropriate metadata, workflow,
behavior, and other settings for different kinds of items
• The lists/libraries that will segregate those items within the sites
• The sites that will contain those lists/libraries
• The site collections that will contain those sites
• The content databases that will house those site collections
• The web applications that will contain those site collections
• The farms that will host those web applications
94. Links
SharePoint 2010 SharePoint 2013 SharePoint Online
Resources for IT Pros bit.ly/SP10-Resources bit.ly/SP13-Resources bit.ly/SPO-Resources
Features and Editions bit.ly/SP13-Service bit.ly/SPO-Service
Limits and Boundaries bit.ly/SP10-Limits bit.ly/SP13-Limits bit.ly/SPO-Limits
SharePoint Maturity Model www.sharepointmaturity.com
Guidance for Modifying Pre-Defined Taxonomy bit.ly/17KHAuw
Discontinued Features and Functionality bit.ly/1bhrLKr
95. Links
My Knowledge Management (KM) Resources Click Here
My Enterprise Content Management (ECM) Resources Click Here
My Web Content Management (WCM) Resources Click Here
My SharePoint Resources Click Here
My Records Management Resources (RM) Click Here
Editor's Notes
Hello, everyone! …wherever you find yourself in the world today
And thanks for joining me to learn about talking SharePoint with other people who aren’t immersed in it like ourselves
We should have plenty of time to go over the material.
We’re going to do a quick introduction,
then we’ll get into the nuts and bolts,
and finish up hopefully with some extra time for Q&A
SOUND GOOD?
Currently I’m with a really great company in Boston; we’re also in New York and Chicago and are expanding out west and down south
We were recently acquired by a larger company, Insight, but we’re still called BlueMetal
I’m just over three years into this role; I’ve had about six years of consulting under my belt at this point and previously I’ve been in a corporate role as well
Been working with SharePoint for over ten years now
I’m not a developer!
Major focus is on wrestling with all the acronyms that end in ‘m’… DM, ECM, WCM, KM…
Here’s how to ping me; That’s how you’ll find the slides…
But enough about me…
Let’s get into the challenge we face in trying to talk about SharePoint with users
Granted this doesn’t apply to all of us, but who actually understands what your mechanic tells you when you go to get your car fixed?
How do you feel when they try and explain what was wrong?
Cars are complex machines with even more sophisticated systems these days—you probably go to that mechanic in the first place because you couldn’t really figure it out yourself…
AND you TRUST that they DO know what they’re doing and therefore you don’t really NEED to know exactly what they did.
How about this scenario… Who’s had surgery?
You probably got an explanation from your doctor before your procedure (or maybe after as well) explaining to you what was done, but they probably didn’t use a bunch of terms you’re not familiar with or speak to you the same way they were talking to the other people in green here while it was actually happening, right?
Now I’m not saying it’s like surgery, but
we have this thing called SharePoint...
It can do all of these things…
and more, of course
We have ALL these things to build with; we’re going to pick the right features, set them up a certain way, put ‘em together, and we’ve got our solution…
The problem is:
How do you talk to these people about how to match up what the do all day and how they do it with this platform they know NOTHING about?
And you need to do all that without them becoming…
Your users are used to words like these.
They have not the slightest idea about words like THESE, and these are the terms we’re used to using all the time on our end, right?
Then there are these big important ideas you need to think about when you’re planning for content management, regardless of the platform.
Talking to your users can be very challenging.
There are many different roles you may have to play…
You need to solicit enough information
Along the way you may need to elicit more input
You may be putting some people on the spot to talk about what they do
You’ve got to assimilate what is laid out for you by your constituents
You’ll be spoken to in a context that is probably foreign to you
Eventually you need to spit it back out to verify you heard everything correctly
You may eventually have to communicate needs accurately to any other developers
This is probably not the first time some technical person has tried to help them
They probably have had bad experiences in the past
You may need to console; hold peoples’ hands; let them articulate their frustrations
Encouragement may be required to keep the ideas coming
You’re the master artist
Their problems are in your hands
You’re going to have to design something in SharePoint to fit stuff that wasn’t designed for SharePoint
What you build will be with these people for a while so it’s gotta last
There are probably multiple routes to reach the same goal; which one do you pick?
Sometimes it’s a game of Tetris to get everything to fit into a new site properly, especially during a migration
So you all are sitting out there; what are you thinking at this point?
Do you identify with one or more of these roles?
Some of you may be thinking:
“So wait, he’s saying I’ve gotta play all of these roles just to get some people set up on SharePoint?”
Just be cool
You don’t have to be John Travolta to get this done.
Now, lemme give you a little bit of background on content management so we’re all on the same page.
You’ve got a document
We want some qualitative data about the content to differentiate it from the sea of other documents
How did you get to this document in the first place?
The consideration here is actually less about the document itself – it’s about your USERS, and
It’s about half and half. Some people like to follow a map and street signs along the way to get to where they want to go.
Others like to search for their destination and expect it to come up pretty high in the result set.
What kind of person are you?
Think about your email. If you’re a filer and have tons of nested folders that you put your emails into, you’re probably an green ‘navigation’ person.
If you’ve got all your emails in your Inbox and anytime you want to find something you type in a keyword or you group and sort by sender, you’re probably a purple ‘search’ person.
You have to consider both approaches when planning for managing your content in SharePoint.
Let me put this term out there, CONTENT ARCHITECTURE. What is it?
It’s about Content Management
Here, we’re looking at two parts to the whole
1. A specification. What’s that? It’s an outcome
2. Activities and outputs. We’re talking about a process
It’s part of a process which is going to help you achieve your content strategy and will form the foundation for content management
But I want to bring up one of those more complex terms we saw earlier, and that is…
What is this thing called TAXONOMY?
OK so we’re going to be categorizing our stuff. Cool.
Even more simply…
The goals are helping users FIND their stuff and USE it effectively.
You can’t have a complete content architecture without a taxonomy
Taxonomy is part of the bigger picture; shouldn’t be examined in a vacuum.
Other parts of your content architecture will include policies, workflows, etc.
Remember that content architecture is the foundation for content management
Taxonomy is the map; the plan; the blueprint in SharePoint
My major point here is:
You must plan ahead if you want to get all the way there
The goal is to create Pleasantville.
But you’re going to end up in the Wild West if you don’t think carefully about this stuff
Once we have our taxonomy we need to apply it to our content.
Why do we bother encouraging our users to tag?
This stuff is not black and white or one-size-fits-all.
I cannot tell you today an exact process to follow that will work for everyone in every case for all content.
And if you approach your users or whoever you’re working with on this stuff with the same solution every time, you’re doing it wrong.
But let’s get into some suggestions I have for your process.
If you’re not considering who you’re talking to before you talk to them, it may be pointless to do so.
You need to understand whether the folks you’re going to be presenting to or having a conversation with are, for example, very technical, or not; whether they’re very involved in the business processes or are just in charge of reviewing the metrics or footing the bill; whether they’re SharePoint advocates or they’ve had bad experiences before.
Let’s take a look at some example considerations…
Simultaneous editing
Automating processes
Stopping everyone from clogging up Inboxes with attachments
Taking advantage of version control
Organizing and tagging the documents
Considering records management
We can talk about all of these goals without even mentioning the ‘S’ word.
Tell people how things are going to proceed so they know what to expect.
Here’s an example of setting a group’s expectations about how you’ll proceed and also importantly when.
Usually it’s more productive to have several smaller sessions with people than to try to do one marathon day of requirements gathering and planning.
Iterate.
Give them homework.
Come back at least a second time and review.
Fancy terminology may make you look smart but can leave your users feeling left out and won’t help them to help you understand what they need.
You should be able to talk about content with your users completely outside the context of the platform you’re ultimately going to be using.
LATER, you’ll start to apply the features and capabilities of SharePoint to what you discovered.
I have a client that was going into meetings with each of their teams they wanted to set up on their new SharePoint collaboration environment, and they started off by giving them a tour of the template they had made up and then asked the team things like:
So what libraries do you need?
What web parts do you want on the home page?
This was entirely unhelpful because they assumed the team they were talking to knew these SharePoint terms and were ready to translate what they do into the context of SharePoint componentry.
Instead…
Ask some generic questions.
Assuming that we’re talking to a particular team about their own content…
This is an actual example slide I used in helping a team think about what kinds of content they worked with and what bits of information they would need to keep track of on each.
Later I mapped out for them the content types and metadata structure I was proposing, but I didn’t put it to them in those terms!
A picture is worth 1,000 words, right?
Here is the whiteboard after an actual discussion I had with a client about all the kinds of content that they worked with. Little did they know that I was starting to map out a content type structure for them at the same time.
You’re going to hear some common things from different teams that should lead you down certain paths.
Maybe they need a dedicated space for each relationship with shared calendars and contact lists
Maybe they only need to allow access to particular documents at certain times
Get the users to walk you through the processes
Users need to be clear about who might have access to something once they put it there.
Think about a separate library, site, site collection…
Instead of planning to grant permissions to external users to a particular document, have an appropriately marked designated space, or provide for the opposite.
You could establish that the entire site is open to the external group and have a library marked ‘Internal’ with more limited permissions, OR you could have the entire site closed to the external group and have a library marked ‘External’ with more expanded permissions.
What are your users going to understand; what is the easiest most clear approach?
Think about the management of those groups
Try to avoid the co-mingling of many SharePoint Groups
Don’t overengineer with a separate site for each project if they’re hardly going to be used
Here’s a few slides of how you might illustrate the advantages and disadvantages of two different architectures
And of course before diving into the details, here I have a picture to illustrate!
This is a rendition of projects being handled as document sets.
Here is an alternative approach where projects are their own sites.
Again, I have the details AFTER showing the illustration!
Think about the different building blocks you have to work with IN YOUR OWN HEAD as you’re listening
Our content types and our site columns are building blocks that can be used/instantiated in different places to effect different results and support our goals of finding content and making it usable within SharePoint
SharePoint gives us several layers to work with from the farm all the way down to individual items.
It’s important to understand what can be configured where and the scope of those decisions.
Line of demarcation
On-Premise vs. the cloud
As you’re thinking up a solution in your mind, hold it up against the constraints and opportunities of SharePoint’s structure
So in understanding your taxonomy and how it’s going to work and support your business processes, manage your content, comply with your security requirements… you need to understand the holistic view of how all of these things will work together in SharePoint.
Work your way up the layers
Again, there’s that line of demarcation.
If you’ve heard the saying “Measure twice, cut once” you know what I’m talking about here. You want to minimize the amount of rebuild you have to do.
This could involve anything from informally reviewing your solution to formal usability testing.
This is really handy for categorization but also for validating a navigation structure you’ve come up with.
Once you get to the point of drawing up specs that actually reference SharePoint componentry, give your users some pictures.
They’re not going to digest a table of content types, libraries, and site columns, but they can probably understand something like this.
If there isn’t a sharing culture, your Yammer implementation will probably fall flat on its face.
If there are team members who don’t want to take on the extra responsibilities of reviewing some type of requests in a new workflow, they could become a bottleneck.
If people aren’t ready to move away from the folder structures they’re used to on their shared drives, don’t immediately take that away from them.
YOU’RE the expert. Own the conversation, make people feel comfortable enough to participate, and go over everything you heard AFTERWARDS. DON’T try and fix the problem immediately; you may just skip right over some additional key information.
(as much as possible)
If you don’t go through this process and plan and communicate across all of the participants, stakeholders, sponsors, etc…
I want you to think about this stuff BEFORE you let content pile up in your sites.
Talk to them! They know their content! IT’s role should be to set up all the gears and plumbing. The business knows its content better than you do.
Don’t try to impose too much governance on user who are used to managing their own stuff
You’re going to need to go back to these people and check in with them; see how it’s going, and make some tweaks