Train Your End Users Or...

It’s official – I’m ignoring the fact that May 12th, 2010, is the launch date for SharePoint 2010 & Office 2010 – sorry, I’m a little busy right now. As I hinted last week, we recently replaced a production fat-client system with a SharePoint solution. Truth be told, the fat-client wasn’t all that fat, the system also wasn’t that well written... don’t ask. The people using this system spend a lot of time in SharePoint so when they asked me to fix this system, I suggested moving the whole process to SharePoint. They liked that idea, I liked the idea, but our experience adds further weight to the message of last week – either “train your users or build their solutions for them”.

The solution in this case is a simple Custom List with a few Lookup columns, a validation workflow and a few custom views. The users in this case know what they want, they are some of our best SharePoint users, but they don’t want to build the SharePoint they use. We (in my department) on the other hand, love building SharePoint solutions. When we built this list, we replicated the functionality of the fat-client and we added the new features that the users wanted. We back-filled the data, tested and deployed the solution and wham – open up the complaint department. “It takes a lot longer to make an entry to the SharePoint list than it did to the previous system.” On further examination, we discovered that the thing that was taking longer was the Lookup columns, these replaced text fields in the old system.

It was faster to enter a few characters into a non-validating text field than to find the right value in a list, but the result of entering those characters was often inconsistent. “John Smith” vs. “J Smith” vs. “jsmith” vs… well, you get the idea. If the users were designing this solution, they would replace the Lookup Column with a Text Entry box – that would be too many mistakes to list here. A little more investigation revealed a relationship between those lookup fields, one of those “if A then B and C” type deals. When I suggested that we could let them start from a quick menu that I could build in SharePoint Designer and then present them with a new list entry that was about 75% complete, they became very happy. While we were having the discussion, we asked a few more questions about the way they work and we added a few more tweaks to the list. Now we are busy building Custom List v.2.

For every Laura Rogers and Mark Miller in the SharePoint world that would build the perfect solution, there are likely a few thousand Larry Curly and Moes that would create, as Dilbert might say: “a smoking pile of failure.” Even when people start to learn how to use the more robust Web Parts, that doesn’t mean they should be allowed to solo. Very often, when people learn how to use a technical feature, it becomes their feature-of-choice – this is the origin of the adage: “if your only tool is a hammer, every problem looks like a nail.” Should SharePoint design and development be restricted to IT? Absolutely not! End users should be encouraged to learn more about SharePoint, but the education should not begin with: “here’s how to write a workflow”, we need to start with fundamentals. In a few weeks, we will invite our end-users to see the solution I’m talking about here. We will walk them through the choices we made, the reasons we made those choices as well as the results. We will encourage them to look at the SharePoint solutions they use and consider how they could be better or, if they don’t know the answer to that, then to simply write down what they don’t like. Then they can discuss their ideas with us and we will either help them make the changes or we will build them the site they really want.

"Funny how that works, eh?”

Back in November, I gave a presentation to the New York Smalltalk User Group at which I explained why our need to connect our business applications to SharePoint almost drove us away from Smalltalk. The presentation generated a number of comments and one that I liked was from Richard Sargent:

“I have to admit, I was wondering what the fascination with SharePoint is ‘out there’. The examples I have seen in the last few years are rubbish, nothing but repositories for randomly disorganised junk…if there is anyone using it for anything different than a document dump and a web-based spread sheet, I'd like to know!”

Of course, I pointed out we are using SharePoint for more than that, and that our site isn’t rubbish. A few emails later he selected one of my earlier comments and sent it back to me. I said: “We work hard to define the requirements” and I could almost sense a little smugness when he replied: “I think that is what sets your SharePoint sites apart from the garbage I have encountered… It's funny how that works, eh?”

Systems developers know how important requirements are and we all tend to feel a chill when we hear the words “end-user development.” SharePoint isn’t the first end-user development environment I’ve encountered, I think that was dBase III, and what always scares me is the implication that 'anybody can do this'. I want to add a disclaimer like Adam and Jamie on MythBusters – “Don’t try this at home”. If you are going to avoid rubbish, you have two choices: 1) Train your end-users, or 2) Don’t give them anything more than Contribute permission.

Train Your End-Users – That sounds simple enough, but it’s more than teaching them where to find the Create menu. You have to make sure your users understand the various platform components: Sites, Libraries, Lists, etc. and their various incarnations. They need to know the difference between a Document Library, a Document Center and a Publishing Site. They need to know how to add Custom Columns to a library or a list and they need to know when and why they need to add them. They need to know what the company vision is for ECM and SharePoint and how to map their requirements into that vision. It follows that you need to have a company plan for SharePoint in which you establish that vision.

Lock Them at Contribute – This approach may make you feel better but it isn’t going to work unless you are prepared to build everything your users need. People know what SharePoint can do and they want those options to be made available. If you don’t let them build their own sites, and you don’t build those sites for them, you are going to watch SharePoint fail, or worse, spawn home grown solutions either on workgroup servers or in the cloud, or much worse, more rubbish in file shares.

We have opted to chart a course in between these two extremes, albeit we are closer to the “contribute” shoreline. We respond quickly to user requests for SharePoint resources, either on our internal or our Internet facing farm. But, as I mentioned in a series called Timeless Lessons, responding quickly doesn’t mean building sites quickly. We take the time to understand the users’ requirements and to satisfy those requirements. At the same time, we invest heavily in training. We have an in-house training program featuring a new topic every month. Some of those topics are SharePoint specific but all of them address any SharePoint implications. For example, if we are teaching a class on PowerPoint, we include a few minutes on our SharePoint Slide Library. Since we use SharePoint for ECM, we conduct ECM training too. We have examples of end-users who design their own sites, customize their sites and we’ve had a few successful end-user constructed sites. But, in each case we have been close by, like the Fire Department during a taping of Myth Busters.

Hope Is Not a Method

Last Tuesday, our Chairman opened our Annual Meeting with a speech that, among other things, talked about the challenges ahead of our organization. Knowledge Transfer is one of those challenges. Then, he talked about the tools we are using to meet these challenges; Enterprise Content Management (ECM) is in that list. Those of you familiar with this blog know about my experience with our ECM effort. Those of you familiar with ECM know how important management support is to an ECM project, so you understand how happy I was to hear ECM being mentioned in the Chairman’s speech.

After the business meeting, Admiral James Ellis, CEO of the Institute of Nuclear Power Operations (INPO), delivered an amazing keynote address. His presentation had been uploaded to our Internet-facing SharePoint site earlier and I noticed that the title began with “Hope is Not a Method” then trailed off after a few letters. I found the partial message intriguing and I asked him for permission to use it. He said he didn’t mind, because it wasn’t his message. Ironically, listening to his speech, I think it was part of his message. As Admiral Ellis described INPO, its history, operational characteristics, mission and its vision, it became clear that INPO’s success was not a series of random events. Their success is the result of skill, analysis, careful planning and systematic effort according to that plan – no hope involved. His was a speech that reinforces the notion that if you have the knowledge, are prepared to work and, if you work, you will succeed.

I love hearing stories like that. Success stories are the single best tool we have to muster support for SharePoint and ECM. I’ve written here before about how I publicize our success stories within our organization – nothing sells SharePoint like the successful use of SharePoint. Everything else we say is marketing hype; we might be slightly more credible than Microsoft, but it’s still “picture yourself doing this” and “wouldn’t you like to solve this problem?” – with all the credibility of EPA estimated gas mileage. If that’s your approach to marketing SharePoint or ECM within your organization, you are currently hoping for success.

I’m not sure who typed the message that accompanied Admiral Ellis’ presentation. I’m not even sure that the title string was the complete message. One thing I do know for sure, I like that message – hope is not a method of any process, if the goal is success.

Picture note: Our Annual Meeting was in Ft. Lauderdale, FL. it was nice to be able to take a picture that didn’t include snow and ice so I just had to use it here.

Back on Track

Before my iPad rant, I was talking about working with hard copy, red pens and a lot of people. People talk about WAM, walk-around-management, I guess this has been WAC, walk-around-collaboration. The good news is these documents are done, they all look great and we are about to distribute them to a very important audience.

That will allow me to return to SharePoint, systems development and the more mundane aspects of running a small IT shop like ordering toner and perhaps finding my desk. Before I leave these documents behind though, there’s one last detail to complete, and this one’s in SharePoint. Each one of these documents has a life going forward, and this year, I’m going to make sure that we are properly set up to support the future role each one plays.

Access – First and most important, each of these documents will be clearly identified, properly described and easy to find. When someone says “I need an electronic copy of the 2009 Annual Report”, there will be no question about where to go. In addition, I’m going to create the site for the 2010 Annual Report; when it’s time to start development, everything we need will be close at hand, including “field notes” containing the tacit knowledge that comes from grinding through this process.

Repurpose – This is an ECM term that most people haven’t heard but it describes a function they all perform. The documents we prepared have a wealth of company descriptive information in them and bits and pieces will likely be reused. It won’t take long before someone asks for “…a copy of the picture that was on page three of the Annual Report”, or if they can get a copy of “the write-up in the new brochure about…” All of these images and text components are in a folder, ready for reuse. Beyond that, the slides from the Annual Meeting will soon be in a slide library. These are good things for two reasons: First, it saves time; people shouldn’t have to recreate that which is already done. Second, it results in consistent stories. The worst thing you can do is give a presentation that contradicts something you said in a different document.

Navigation – If you search this blog for ‘navigation’ you will probably find it close to a word like “difficult”. SharePoint navigation is one of the things our users complain about and one of the harder nuts we’ve had to crack. We are getting better, and my goal with respect to these documents is to never have someone ask me where they are. I also don’t want to rely on search, I think important documents should be easy to find via an intuitive process. I’ll let you know how that works.

No iPad For Me

I hate it when something new and cool is announced and I don’t have one; especially when I could have one if I could justify it. Such is the case with the Apple iPad. Yes, I understand the iPad doesn’t actually exist yet. I also understand that everything I’ve read about the iPad is either marketing hype or the result of a handful of analysts groping the prototypes and reading technical specs. Still, Apple isn’t likely to let misconceptions run wild, so I’m guessing that what we’ve heard is close to the truth. Why won’t I get one? Well, consider what it is that I wanted.

I was hoping the iPad would be the perfect device for a niche group of my users: those people who primarily consume information rather than create it. Today, I arm these people with fairly expensive lightweight laptops. By lightweight, I’m referring to mass, not capability. The problem I have is these lightweight laptops are very capable, and I’m paying for the capability. My hope was that a lightweight (mass and capability) device from Apple would satisfy their technical needs and be just cool enough so that these people would want one. If I could deliver an awesome tablet to this group, for less than half what I pay for the heavy-duty laptops – well, that’s got hero written all over it. And here’s the best part, I would need to have an iPad of my own, you know, for testing.

Does the iPad deliver? These people need email access. Assuming the iPad works like an iPhone, I know I can connect to my Exchange server and control the security – done! These people need to be able to read and occasionally edit Office documents. Okay, if we assume a slightly better version of Documents to Go (DtG) is released, I may have a viable solution but not a great one. DtG is good but it’s not Office. That means I have to provide training. And, since the goal was to eliminate a laptop, what does DtG sync with? I know it syncs to the Cloud, which just happened to be my next wish. I was hoping the iPad will support SharePoint. This wish may be granted, but more by Microsoft than Apple; SharePoint 2010 will support Safari but will the iPad support Silverlight and Flash content? Doubtful. So far, three goals, and I have a “done” a “probably” and a “we’ll see” – not a great start.

In addition to the unanswered questions, there are several things I don’t like about the iPad: First, no USB ports. "But wait, you can connect a USB device using a dongle." Do you know what “dongle” means? It’s a technical term that means “small, expensive, proprietary connecting cable that is easily lost, and only available from the manufacturer, or from vendors inside the TSA protected zone at major airports” – yeah, I’m going to need to keep a dozen of those in-stock. Next dislike: multi-tasking, or rather the lack of multi-tasking. I didn’t know how much multi-tasking mattered until I tried the OCS App for my iPhone; if ever an app needed to run in the background, it’s OCS. Apple says multi-tasking consumes too much battery life but I can control that as a user; let applications have a “run-in-background” option. Third dislike: the lack of tabbed-browsing; I can’t imagine using SharePoint in a non-tabbed-browser. Yes, I know, Safari (on my iPhone) is a kinda-sorta tabbed browser but I want the real thing, complete with options to “open in new tab” or “open in new window”. I want to open the browser with multiple tabs already loaded! God help me, I want it to be like I.E. v8! Oh, and tethering; AT&T, could I at least tether my iPhone to my iPad?

The biggest thing I don’t like about the iPad, the show-stopper for me: the iPhone OS. I was really hoping for a machine I could write code on. I was prepared for it to be pathetic, I was prepared for it to be limited, I just wasn’t prepared for it to not be possible. I want to write apps for our users. To do that, I have to buy a Mac. Of course, I can build the customization into SharePoint, as long as I don’t use Silverlight, but that means I have to spend more time in Windows so others can enjoy the iPad experience.

If I’m wrong about a few of these assumptions, maybe I can buy one, you know, for testing. If I’m not wrong; and Apple, if you’re listening, give me an option in the next generation device. Give me the super-iPad with a real OS, two USB ports, Flash support and a development environment, and I’ll buy one even if you call it the Max-iPad.

iPad, Apple, Mac, Mac OS, iPhone, iPhone OS and probably the lowercase “i” are property of Apple and protected by trademark, copyright or some such thing. The image is an actual picture of my iPhone, as I doubt I can draw a red circle and line through the press images of the iPad.

Next Stop – A Workgroup Printer

A recent mix-CD from my daughter reminds me that any song about a train is a good song. Rock, country, folk, blues, whatever genre you have, sing about a train and I’m liking that song. Unfortunately, SharePoint is a little more like a real railroad, it’s great for mainline operations but it sometimes has trouble with the last few miles. Lately, I’m discovering that despite being a great collaboration platform, having a process in SharePoint doesn’t necessarily mean the entire process can stay in SharePoint.

My job this past week has been to edit two documents: our Annual Report and a company Brochure. Both documents were the product of a collaborative effort, with sections being written by several people, but both documents have to coalesce around common themes and common language. We began in SharePoint, on an Internet facing site that our outside designer can access. Schedules, tasks, status, draft text and tons of images were all carefully placed on that site for easy access. Documents were version controlled during the initial draft stages and the process moved as if it were on rails. Then we got the first draft from the designer.

An interesting thing happens once component documents are assembled into a composite - they gain additional context. Suddenly, we see that two people included very similar text that just happens to be on facing pages. Or, we notice that, if we could remove about a paragraph’s worth of text from a page, the text would flow so much nicer around the images. This is the point where most people need to have hard copy and a red pen. You might think that this is where a wiki would be useful, but I disagree. In fact, uncharacteristically for me, I didn’t even make the attempt.

First, it’s difficult to review this type of content on a computer screen. Second, not everyone on this team provided new text; some of the comments I received were things like: “I think we say the same thing on page eight”, or “emphasize the stuff in paragraph two”, or “do we still need to be saying this?” Finally, this process isn’t exactly equal. Several people may suggest changes to a particular section, but only one may be offering the “expert” opinion. You might think it would be easy to delegate this up front, but, if you ever have to manage a process like this, you will quickly understand why that isn’t the case. The fact of the matter is, every subject matter expert is responsible for his or her section, but they really want to look at the whole deal. Of course, once this is done, my job was to make these documents sound like they were written by one person. That task involves other people as well, the phrase “what do you think of this?” became common.

So, was this a week without SharePoint for me? No, not really. This is a process, and even if I can’t use SharePoint to automate and control the process, I can use SharePoint to document the process. When I have to do this next year, or if someone else ever has to do this, there are many important items to remember. Trains are good, train wrecks are not, unless it’s “Casey Jones” by the Grateful Dead or “Runaway Train” by Rosanne Cash.

The Problems SharePoint Solved

aka A Case Against Branding
By Owen Baern

We’ve All Been There - Anyone involved with SharePoint in any meaningful way knows the look that people get when you start trying to explain what you do – that “deer trapped in the headlights / what ARE you talking about” look. You’re at a party and someone asks what you do for a living - I’ve actually started finding myself brushing past the question, in order to get onto topics that are less fraught with frustration, both for me and the individual posing the question. But over this recently past holiday season, I began giving this some thought. If someone were truly interested, how could I explain what I do? I came up with what I’ll call a Really Brief History of Collaborative Technology.

The Bad Old Days - Let’s say you’re a VP in a fairly large company, at the turn of the turn of the century. You need to collaborate with a small group of individuals on a set of documents, a list of the individuals involved in the project, and a calendar of the various meetings you all need to be involved in. Let’s also assume that yours is a company that has a need of confidentiality, maybe there is a threat of legal action, or perhaps you are concerned about intellectual property issues. Consequently, you decide your company can’t use any publicly-available, generic web application. Since this is ten years ago, you go to the head of your IT department and say “here’s what we need – make it so!” And your IT department then goes and spends some money hiring consultants or starts burning internal man-hours. They develop this application, probably in ASP, not .net (remember, not around quite yet). The application, we’ll call it CustomCollab, has a login screen, a calendar, it has some upload/download functionality, it has a contact list, it even has the company logo along the top of the page. This new application is even somewhat secure. Later on, CustomCollab is rolled out to the intranet.

This is the Wheel… No, THIS is the Wheel - Now imagine there are hundreds and hundreds of companies re-inventing this wheel, over and over again - each with a different interface, each with different rules as to how users interact with the code, each with their own quirks.
Furthermore, let’s say you, as the VP of that company ten years ago, decide to leave the company that’s invented CustomCollab and go to a new company. If you’re lucky, you only have to learn how to use a different custom collaboration solution (if you’re not lucky, you’ll have to weigh whether or not you want to push another set of IT professionals to re-invent the wheel again).

Here and Now - This is the problem SharePoint solved! We now have a standard, albeit imperfect, collaboration platform with degrees of security that can be enabled based on your company’s need. We no longer need to re-invent the wheel. We’re not wasting man-hours developing solutions that have already been developed and employees are no longer wasting time learning specific collaborative applications developed for only one company.
In ten years from now, I’m pretty sure we’ll have a workforce that’s mostly comfortable with SharePoint. Imagine going into a company, knowing the technology that drives collaboration.

So Why Brand? - Given this history, why would you take away one of the strengths of SharePoint? Specifically, why would you take away the ease with which a new employee can use your SharePoint –based system because he or she has experience with SharePoint from their previous employer? Just to be clear, I’m talking only about internal use within a company – not SharePoint driving a public web site. Let’s face it - SharePoint’s interface isn’t terribly “sexy,” but it wasn’t meant to be. I’m going out on a bit of a limb here, but I think that the intent of the SharePoint interface was to normalize the interface of the collaborative application.

Why Not Brand? - Having written the above, it may come as a shock to know that I’m a huge fan of branding. (I come to SharePoint with experience as a web designer.) SharePoint reveals itself in the browser through CSS. This is only becoming truer as we follow the evolution into SharePoint Server 2010. Want to know how to get rid of the QuickLaunch by just adding a content editor webpart? Add some CSS code. Want to get rid of the generic look of SharePoint and replace it with your company’s color scheme? Duplicate and modify the CSS.

Either way you go, it’s an exciting time to be involved with SharePoint.