NHSPUG April 2017 - We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint
•Descargar como PPTX, PDF•
1 recomendación•330 vistas
The document provides an agenda and notes for a presentation on how to discuss content management in SharePoint with regular users. The presentation covers the challenges of communicating technical concepts in an understandable way, defines key terms like content architecture and taxonomy, discusses the content management process, and provides overall guidance to make the toolset approachable to users. Examples and analogies are given to help translate technical needs into requirements and demonstrate concepts. The goal is to help users understand and adopt content management in SharePoint.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a NHSPUG April 2017 - We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint
Similar a NHSPUG April 2017 - We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint (20)
Más de Jonathan Ralton
Más de Jonathan Ralton (15)
Último
Último (20)
NHSPUG April 2017 - We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint
- 1. All trademarks and registered trademarks are the property of their respective owners.
- 2. Jonathan Ralton BlueMetal We Need to Talk: How to Converse with Regular People About Managing Their Content in SharePoint
- 3. Agenda First Things First The Challenge Content Management The Process Last But Not Least Questions
- 4. First Things First We Need to Talk
- 5. YOU
- 6. Audience What roles are you in? What SharePoint phase are you in? What are you hoping to learn?
- 7. ME
- 8. Presenter Jonathan Ralton • Senior Information Architect • SharePoint IT Pro since 2005 (WSS/SPS) • No coding! • Document Management, Content Management, Knowledge Management… @jonralton jonathanr@bluemetal.com blog.jonralton.net linkedin.com/in/jonathanralton
- 9. The Challenge We Need to Talk
- 13. 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
- 14. The Challenge Farms Web Applications Content Databases Site Collections Sites Lists Libraries Folders Document Sets Site Columns Content Types External Content Types Managed Metadata Crawled Properties Managed Properties
- 15. The Challenge We have you… We have the users…
- 19. Friendly Words Folders Files Forms Policies Procedures Departments Links ‘S’ Drive wallpapers.in
- 20. Scary Words Site Collections Document Sets Libraries Term Store Content Types Workflows Lookups Web Parts thedogtrainingsecret.com
- 22. The Challenge You’ve got to… • Listen • Advise • Deflect • Elicit • Inform • Prescribe • Prioritize • Moderate …all at the same time.
- 23. Interviewer • Solicit enough information • Elicit more input • Put some people on the spot to talk about what they do thornleyfallis.com
- 24. 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
- 25. 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
- 26. 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
- 27. Gamer • Multiple routes to reach the same goal • Get everything to fit into a new site properly, especially during a migration gamersagainstbigotry.org
- 29. © 2005 Metro-Goldwyn-Mayer (MGM)
- 30. Content Management We Need to Talk
- 31. Content Management What is it? Is it useful to me?
- 33. CONTENT ARCHITECTURE def·i·ni·tion [dèffə nísh'n]
- 34. Content Architecture 1. The specification for a content management solution 2. A set of activities and outputs for effective content management – Cleve Gibbon
- 37. Taxonomy “a classification into ordered categories” – dictionary.com
- 38. Taxonomy A way to group things together
- 40. Content Management What is… • Content Architecture • Taxonomy How do they relate? Content Architecture Taxonomy
- 41. Content Management Your taxonomy is an integral part of your content architecture plan
- 42. Content Management Your content architecture is the foundation for achieving content management
- 43. Pleasantville © 1998 New Line Cinema
- 44. Wild Wild West © 2014 Universal Studios
- 46. Tagging “the act of applying metadata to an item” – Microsoft
- 49. The Process We Need to Talk
- 50. The Process 1 Think about your audience before you sit down with them.
- 51. New to Collaboration Tools Top goals probably should include: • Co-authoring • Workflow • Sending links instead of attachments
- 52. Migrating from File Share Top goals probably should include: • Versioning • Tagging • Information Management Policies
- 53. Building an Intranet Top goals probably should include: • Leveraging the publishing model • Separation of duties • Self-service forms
- 54. The Process 2 Be clear about how you’re going to lead people through discovery.
- 55. Timeline •Content Architecture •User Experience Discovery •Requirements Document •Content Type Chart •Wireframes Design •Content Types •Site Columns •Libraries •Lists •Pages •Web Parts Build Migration Early April Mid April Late April Late April
- 56. The Process 3 Don’t try to figure it all out in one sitting.
- 57. © 20th Century FOX Film Corporation
- 58. The Process 4 Steer clear of those scary words.
- 59. Terminology Not OK OK Site Collections Websites 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, Components
- 60. The Process 5 Examine their content outside the context of the tool.
- 61. 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?
- 62. Discussing Needs Types of Documents/ Content Properties Processes Stuff Others Might Need
- 63. Discussing Needs Types of Documents, Content Metadata Candidates • Research • Reports • Calculation Templates • Independent Laboratory Testing • Presentations • Projects • Analysis • Instrument Documents • Service Documents • Training/Reference • Health & Nutrition • Forms • Links • Clinical Information • Ingredient Database • Presentations • Regulatory • Reviews & Policies • Ingredient Reviews • Claim Substantiation Documents • Presentations • Educational Information/Resources • Training • Vendor Name (dozens) • Fiscal Year • Calendar Year • Laboratory (4) • Instrument (dozens) • Investigator (dozens) • Name • Institution • License Number
- 64. Document Types and Metadata Example • Content Description • Content Owner • R&D Category R&D Document • Content Description • Content Owner • Vendor • Fiscal Year • Calendar Year • Laboratory • Instrument • Project • Product Brand Research Document • Content Description • Content Owner • Vendor • Fiscal Year • Calendar Year • Instrument Analysis Document • Content Description • Content Owner • Fiscal Year • Calendar Year • Investigator Health & Nutrition Document • Content Description • Content Owner • Calendar Year • Project • Product Brand Regulatory Document • Content Description • Content Owner R&D Reference Material • Content Description • Content Owner R&D Training Material
- 65. The Process 6 Draw stuff out, erase, and try again.
- 67. The Process 7 Recognize trigger words or phrases that may lead you to architectural decisions.
- 68. 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
- 69. 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
- 70. 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
- 71. 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
- 72. Project Sets Option PMO Team Site Active Projects Project C Archived Projects Project B Project A Project Z Project Y Project X
- 73. 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
- 74. 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
- 75. 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
- 76. 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 …
- 77. 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.
- 78. 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
- 79. 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.
- 80. 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
- 81. The Process 8 Try to validate what you’re thinking before you go and build it.
- 83. The Process 9 Use pictures along with specs.
- 85. Overall Guidance 10 Don’t push too hard. Go with the culture.
- 88. Last But Not Least We Need to Talk
- 90. Overall Guidance Be approachable. Make the toolset approachable.
- 91. Overall Guidance Bend the tool to their processes, not the other way around.
- 94. Reference We Need to Talk
- 95. Links SharePoint 2010 SharePoint 2013 SharePoint 2016 SharePoint Online Resources for IT Pros bit.ly/1QrGndM Features and Editions bit.ly/1HLZrfG bit.ly/SPO-Service Limits and Boundaries bit.ly/SP10-Limits bit.ly/SP13-Limits bit.ly/28SJAGy bit.ly/SPO-Limits SharePoint Maturity Model www.sharepointmaturity.com Guidance for Modifying Pre-Defined Taxonomy bit.ly/17KHAuw Discontinued Features and Modified Functionality bit.ly/1bhrLKr
- 96. 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
Notas del editor
- Good Evening! So… I’ve got a lot to talk about, sometimes I can go kind of fast cuz I’m trying to keep up the pace, so slow me down if that happens We’re going to do some quick getting-to-know each other, then we’ll get into the nuts and bolts, and finish up hopefully with some extra time for Q&A SOUND GOOD? And please ask questions as we go if something isn’t clear
- Let’s find out a little about all y’all…
- Just so I get an idea who I’m talking to… Do we have any Developers? Administrators? Business people/end users? Are we all currently using SharePoint in our organizations? Anyone in the planning stage? Either for a new environment or upgrading/migrating? Who wishes they could go back to the planning stage? What do you wanna know?
- VERY BRIEFLY about me…
- 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 A little while back we were acquired by a larger company, Insight, but we’re still called BlueMetal Where I had the pleasure of working a lot with Julie over there I’m just about four years into this role; I’ve had about seven 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 here has 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 with SharePoint in mind 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 what are you all 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. You don’t know what’s inside it. 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 Automate some 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. It’s easier on people to break it up and it give them time to digest and think. Sometimes it’s better to introduce new ideas to people slowly.
- 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. If you have access to those large post it pads, they are handy to take with you or you can take a picture of them
- 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. Think about isolating information from different external partners. What are your users going to understand; what is the easiest most clear approach?
- Think about the management of those groups Also think about how they might need to be used—AD groups can be nested; SharePoint groups cannot—AD groups can’t be split apart in a workflow; SharePoint groups can—SharePoint groups can be used to constrain a people picker column; AD groups cannot 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
- If you do…