Evangelism in a Hostile Land

It may be hard to believe, but there are still organizations out there where “SharePoint” is a dirty word. Maybe they haven’t upgraded, maybe–and this is worse–they do have a SharePoint Site but it’s been badly managed, acting as little more than a badly-setup document storage bin. Users see no reason to switch from their old, bad habits of email, PowerPoints, and storing files in their personal drives (because they know they can find it there).

That was the situation I found myself in when I switched to a new team. They had a Site (because they’d been told to use it) but after years of mismanagement, its faults were far too numerous to get into here; suffice to say, it shouldn’t be deleted but rather preserved for all time in the Museum of Worst Practices as every example of how SharePoint could be misused to prevent people from doing their work. Users were, to say the least, antagonistic towards SharePoint.

All I said was, “You could use SharePoint to do that,” I swear!

Now, they’re using Pages, Lists, and Libraries interchangeably, even customizing their own solutions. SharePoint is looked on as a tool to help them automate their work, not just a filing system. Less and less, I’m asked “Can you make me something to do x” and, instead, I’m told “Look at what I made that does x, y, and z!”

Here’s my approach to go from “SharePoint sucks!” to full adoption.

Step 1: Plan big

Step back and get the ‘lay of the land’, see how the team does their work. Observe existing processes and think about how to streamline them. Look…but do very little…because you have other work to do first.

Think about the end result for your Site and what it could accomplish, the Big Picture. Sketch out what the homepage might look like, what dashboards might be useful. Design a permissions architecture that fits the organization. Draft up some governance rules and policies for how the Site should be run; from then on, use those guidelines in everything you set up. These aren’t etched in stone, you can adapt them later, but it’s better to start with some guidelines and governance than to make them up as you go along.

Once you’ve got your vision of the Big Picture in place, move on to…

Step 2: Start small

Isolate a small sub-team or group within the team at large. Talk to them and get to know their needs, their processes, their inputs and outputs. What do they want to track? What could be automated? How can SharePoint help them?

Figure out how their work will fit into that Big Picture and now start planning. Design your SharePoint solutions for the sub-team with that in mind. What columns in their Lists might be useful to others…and make them site columns. What dashboards do they want that could, later, be trimmed to become the dashboard View at the manager level.

Also, when dealing with the small group, identify potential allies, people who ‘get’ what SharePoint does. With the right encouragement and training, these people can become your advocates later on, your points-of-contact for using and building the Site.

Once you’ve got a good design, get ready because it’s time to…

Step 3: Build small

You might think you want to ‘wow’ them, show off the full power of SharePoint, make them something so pretty and wonderful that they sing its praises far and wide. But a highly-customized solution with a lot of automation might make them wary of the big changes you create. So, when building your solutions, start simple and let them see the gears at work. Put away your javascript codebooks, close SharePoint Designer, forget you ever heard of InfoPath, set aside your content-types and workflows (for now).

You can usually start solving their big issues, the tasks that take up a lot of their time and effort, with a Page or two, a Library, and a few Lists with the right Views for the right purpose. Don’t shoot for a 100%, totally complete solution that does everything for them; aim instead for a simpler solution that they can grasp how it works. Make it vanilla, make it OOTB.

That doesn’t mean you should throw out every cool trick and elegant solution you’ve ever learned how to do. It just means that you should build small enough for them to see “behind the curtain” (The Wizard of Oz, 1939). It will be less daunting for them to use if they know what buttons to push and levers to pull to be wizards themselves.

SharePoint Designer, circa 1930s

Your subteam is set and starting to use their initial SharePoint solutions. Things are starting off well so it’s time to…

Step 4: Move on

Leave your initial group to do their work. You’re not abandoning them, you’re letting them simmer. Go on to another subteam and repeat Steps 2 & 3. Find out what they need and build them something small. Keep on doing this until you’ve got a few groups working on the Site.

After a while (few weeks? a month? hard to define), don’t forget to…

Step 5: Check back

Circle back to your first group. By now, they should be very satisfied with your solution because they can see how it’s helped them do their work. The old ways are happily abandoned in favor of automated displays and dashboards.

They’ll have suggestions, ways to improve their Site. They’ll also have populated enough data–files, items, whatever–that you can use to better ‘see’ their processes at work. Get them to draft up their SOPs for how they work now. Work with them (don’t forget your ID’d advocates! get them to help!) to see what could be made better. Ask them flat-out, “Dream big! What do you wish you had now?”

This is when you pull out the big guns you set aside in Step 3. Customize workflows, add javascript, dust off SPD and InfoPath. Start showing them the “wow” factors…unlike before, they’ll be happy to change their work processes a little because they’ll know, deep-down, where they’ve done the work themselves, how it can be better.

Keep working your way around, moving from subteam to subteam, until you’ve done enough to…

Step 6: Put it all together

The management level at the top of your whole team comes in, basically, two flavors (with variations, it’s a spectrum). One, they want know enough about SharePoint to get it implemented properly and quickly. Or two, they don’t know it at all and are hesitant to change what they do in favor of the latest “fad” (never mind that it’s been around for more than a decade!). Either way, you can’t leave them out of the loop with all of these steps that you’re doing. Just tailor your approach to their attitude.

With the first set of managers, it’s relatively easy. Give them regular updates. Show them how their subteams are working better and faster. The only caution is not to move too quickly; just as in Step 4, the whole team needs to simmer, to adopt SharePoint gradually.

With the second, assure them that the work is still being done. There will still be antiquated processes (daily emails! PowerPoint briefs! weekly activity reports!) to do and none of your subteams should stop doing those in favor of your solutions. After all, your solutions should be aiming at those progress reports as outputs, to make the subteam’s work easier.

Once you have enough to work with, make a manager-level Page, “One Page to Rule Them All” (The Lord of the Rings, 1954). Put in Web Part dashboard Views that display information useful to the manager. Build enough ways to drill down if they feel curious about how everything is going. Show it to them and explain how it can replace some of those old ways. Once they can see it in action, they’ll probably be more amenable when you push for further adoption of SharePoint.

Because you’re not done. Oh no, *wry chuckle* now you’ve got real work to do, it’s time to…

Step 7: Level up

Everything is modular. Nothing is ever truly finished. There’s always more work to be done. However you want to look at it, now that you’ve started bringing the team into a SharePoint future, consider the following:

  1. Formalize your Site governance by writing it up as a policy. Enforce it.
  2. All those Lists and Libraries you made in Steps 3-5? How can you use site columns, content-types, and workflows to make them more efficient and effective across your Site?
  3. Turn your advocates into acolytes. Train them to use SharePoint themselves.
  4. Documentation. Are you writing it all down? As more users adopt SharePoint and the changes start multiplying, do you have a good documentation plan built into your Site governance?
  5. More users, more data. And more headaches. Keep monitoring your Site to see what might’ve worked OK when it was small but is now a problem since it’s grown.
  6. The Big Picture changes, always. That vision you came up with in Step 1? Don’t be afraid to adapt it, tweak it, change it entirely. Be flexible!
  7. We are not alone (Walter Sullivan, 1964). Unless you’re a solo small business, there are always more teams, more levels (up/down/sideways) to deal with in your organization. How does your SharePoint Site fit into what they’re doing? How does your team’s inputs and outputs match up with their inputs/outputs?

Knowledge Curation

I was working with a group of folks the other day who wanted to redesign the site. They had a lot of ideas for one page. They had no ideas for the data that supported what they wanted to present on that page. The site collection already has very poor architecture. When one goes to the root site to the site collection, that person gets two redirections to the final page on a subsite. Whoever created it that way caused all of the lists and libraries on the root site to go untouched for about a year.

In my discussions with them, I had to give them the analogy of a kitchen remodel. One doesn’t just put in a new kitchen. You need plans. You need to do demolition work. You need to account for the electrical, gas, and plumbing that you cannot move. You also need to figure out what you are going to keep from your cabinets. They had a good 30 or more lists and libraries that hadn’t been touched. I’m not going to just leave those defunct lists and libraries there. A new page would be a mere façade over a weak structure.

Over the coming weeks, they are to look at the existing content and identify what they are going to keep and what they want to kill. This is always the first step in redesign work with SharePoint: Knowledge Curation. It could be information curation, but we need to identify why and they are vetting the value of the information, so I elevate this to knowledge. They aren’t just checking to see if something is properly tagged. They are doing more than content management, and it is grunt work because no one had previously built the tools for them to sift through it more easily.  To learn more about knowledge curation, here is an article I looked up from KM World.

The next step will be to identify the data definitions of those things they would like to present on the page like pictures on a carousel. I’d rather them not need to do a lot of work to keep their content there, so they need to identify what determines whether or not a picture will be displayed, how they want to add a new picture, if they link, etc.

We will go about creating their content management plan and will have a section for knowledge curation. It should be a continuous process, not something you do once a year. It is like brushing your teeth daily versus getting a scaling once a year by your dentist because the plaque looks like you have fused your teeth together. At some point, your dentist will recommend pulling your teeth and getting you dentures. This is why you see so many people start over with SharePoint sites. They neglect them for so long, they would rather just build a new one. It takes discipline, and it takes a plan.

Scott Brewster works for Data Analytics Solutions. He is got his Certified Knowledge Manager (CKM) credentials through the Knowledge Management Institute (KMI), and he has been working on both the farm administration and front end solution architecture of SharePoint since 2008.

Views Instead of Permissions?

Recently, a former Site Collection Administrator tried to convince me to use views instead of permissions. Why would anyone want to do this? Their thinking was to allow for easy document placement on different pages (one site collection) using views and filters. There are times when using views or audience targeting to solve what an audience can see is effective, just remember this is not always the case. Adding site pages can add an additional layer of security by requiring permissions to view the page first, and then the content on the page. Can we discuss the 2 kinds of users who can still find the content not meant to be seen? The first group of users are the ones who aren’t familiar with SharePoint or who aren’t “tech savvy” and just click around and find content by mistake. The second group of users are the more advanced users who will look at URL structures and navigate curiously through them.

Using views, a person can limit what information is seen by the naked eye. Those list items or documents are not secure by any means, just hidden from plain sight. Let’s never forget the basics of SharePoint. One of the main advantages of using different document libraries or lists are the fact that each one can be locked down with unique permissions. Segregating the data can make it more secure but also makes it challenging to present it to the intended audience in the exact way that is envisioned.

In SharePoint, there are always multiple ways to accomplish the same goal. Don’t skimp on security in place of functionality. Security is about risk & risk mitigation. In dealing with government networks and corporations, the stakes of security is extremely high. Content ranges from trade secrets to classified information. Even small and medium sized business have internal documents that only warrant certain eyes.

Security must always be a priority when designing SharePoint sites and content. Views can hide content from certain users, but security through obscurity can only be used when the content isn’t sensitive. First secure the content appropriately, and then figure out how to deliver it to those who need access.