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. 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?