Collab365 - We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint

Editor's Notes

• #3: 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?
• #4: 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
• #6: 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.
• #7: 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
• #8: we have this thing called SharePoint...
• #9: It can do all of these things… and more, of course
• #10: 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…
• #11: 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…
• #15: Your users are used to words like these.
• #16: 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?
• #17: Then there are these big important ideas you need to think about when you’re planning for content management, regardless of the platform.
• #18: Talking to your users can be very challenging. There are many different roles you may have to play…
• #19: 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
• #20: 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
• #21: 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
• #22: 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
• #23: 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
• #24: 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?”
• #25: 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.
• #27: You’ve got a document We want some qualitative data about the content to differentiate it from the sea of other documents
• #28: 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.
• #29: Let me put this term out there, CONTENT ARCHITECTURE. What is it?
• #30: 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
• #31: 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…
• #33: What is this thing called TAXONOMY? OK so we’re going to be categorizing our stuff. Cool.
• #34: Even more simply…
• #35: The goals are helping users FIND their stuff and USE it effectively.
• #36: You can’t have a complete content architecture without a taxonomy
• #37: 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.
• #38: 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
• #39: The goal is to create Pleasantville.
• #40: But you’re going to end up in the Wild West if you don’t think carefully about this stuff
• #42: Once we have our taxonomy we need to apply it to our content.
• #43: Why do we bother encouraging our users to tag?
• #44: 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.
• #46: 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…
• #47: Simultaneous editing Automating processes Stopping everyone from clogging up Inboxes with attachments
• #48: Taking advantage of version control Organizing and tagging the documents Considering records management
• #49: We can talk about all of these goals without even mentioning the ‘S’ word.
• #50: Tell people how things are going to proceed so they know what to expect.
• #51: Here’s an example of setting a group’s expectations about how you’ll proceed and also importantly when.
• #52: 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.
• #53: Iterate. Give them homework. Come back at least a second time and review.
• #54: 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.
• #56: 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.
• #57: 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.
• #58: Assuming that we’re talking to a particular team about their own content…
• #59: 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.
• #60: 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!
• #61: A picture is worth 1,000 words, right?
• #62: 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.
• #63: You’re going to hear some common things from different teams that should lead you down certain paths.
• #64: 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
• #65: 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?
• #66: Think about the management of those groups Try to avoid the co-mingling of many SharePoint Groups
• #67: Don’t overengineer with a separate site for each project if they’re hardly going to be used
• #68: 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.
• #70: Here is an alternative approach where projects are their own sites.
• #71: Again, I have the details AFTER showing the illustration!
• #72: Think about the different building blocks you have to work with IN YOUR OWN HEAD as you’re listening
• #73: 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
• #74: 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
• #75: 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.
• #76: Work your way up the layers Again, there’s that line of demarcation.
• #77: 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.
• #78: This is really handy for categorization but also for validating a navigation structure you’ve come up with.
• #79: Once you get to the point of drawing up specs that actually reference SharePoint componentry, give your users some pictures.
• #80: They’re not going to digest a table of content types, libraries, and site columns, but they can probably understand something like this.
• #81: 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.
• #85: 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.
• #87: (as much as possible)
• #88: If you don’t go through this process and plan and communicate across all of the participants, stakeholders, sponsors, etc…
• #89: I want you to think about this stuff BEFORE you let content pile up in your sites.
• #90: 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
• #91: If you do…