Baby Steps

clip_image002What do SQL Server, Social Media and SharePoint have in common? They are all things that we are learning, or still learning and they are all places where we just might make some mistakes. Earlier this week, one of my team members had to make a change to the structure of a table that we are using while testing our connections between SharePoint and our backend database. The change triggered that queasy-feeling-generating message about having to drop and recreate the table:

This young woman leans toward cautious; she started exploring the options for altering her approach. I’m not sure she appreciated my advice, which came wrapped in a question: “what’s the worst that can happen?” After all, it’s a test database. I tried to sweeten the deal by adding that “we might as well see if this works” and that even if it failed, it would “give our system administrator a chance to test his backup and restore process”.

While she was struggling with SQL Server, I was learning more about using social media in our business. I spent a good part of this past week at the Enterprise 2.0 Conference – Boston, now officially known as E2Social, listening to people talk about effectively using social media to promote or grow your business or using it to improve communication and collaboration within your organization. In all these sessions, one message came through clear – mistakes are going to be made. After reading this far, you probably won’t be surprised to learn that I’m not bothered by that fact; we’ve been making mistakes with SharePoint for years. The important thing to know about those mistakes is that none were very large, none cost our company any much money and every mistake was a learning experience. Nathan Bricklin, Head of Social Strategy at Wells Fargo summed it up in his keynote presentation at E2. I’m paraphrasing here, but the quote I loved was:

“if you take baby steps and fall, you can learn walk. If you plan a project for a year and fail, you won’t be able to figure out what you did wrong”

The other feel-good moment in his presentation was when he reminded us that: “…it’s like baseball, you can’t win or lose the game in the first inning” that quote might not have been all that well received at this point in Boston, but we all understood the underlying message.

In our office, we have been playing this game all year as we have been experimenting with the various ways we can connect SharePoint to our backend data. We realize that if we can tie structured data to unstructured data, we can automate, or support through automation, a much more significant part of the target business process. Unfortunately, trying to make these connections has been underscoring why the word “frustrating” in in my tag line. We have managed to assemble successful proof-of-concept pages, parts, lists and workflows for almost every feature that we need to use. We have run into almost every error you can generate (they all seem to be related to permissions) and we have solved or worked around most of them. In short, we have fallen, but we are learning how to walk.

I never have much luck when I predict what next week’s post will be, but if things go according to plan, I’ll be sharing some of the specific experiences we have had with our connection quest. If things go according to history, I’ll be talking about something totally unexpected that will happen during the next few days.

By the way, if you want to know how to make it possible to let SQL Server drop and recreate those tables, see Geoffrey Emery’s excellent blog entry from 2009. I discovered that shortly after we began our migration from DB2 to SQL Server. DB2 warns you when a table has to be dropped and recreated, but it lets you decide whether or not you want to make the attempt. Unless you change your settings in SQL Server Management Studio, you get the warning shown above, but you can’t actually proceed. I will add for the faint of heart, that once you make the changes that Mr. Emery outlines, the drops and recreations just happen, no muss, no fuss, but no warning.

Road Trip

clip_image002Road trips come in three varieties: You need to get from point A to point B, you want to discover something or you want to show somebody something. I’ve been on way too many of the first type, including two where points A and B were 3,000 miles apart; those trips are not always fun. Trips of the second type are almost always interesting, but the third kind of trips are the ones that are fun. When it comes to SharePoint, it’s the same story.

We have been on the first type of road trip for the past few months. We have built out a complex document handling project, aided by content types, workflows and bits of metadata. In addition, we spent time wiring up a bunch of Data View Web Parts and detail views of this content to elicit some management information about the process and present it on a dashboard. Those were the major goals of the project, comprising points A, B and several others in the alphabet. We are just about to call the project done. Handing the management dashboard over to the department VP was a rewarding moment, but late last week we took this project on its own little trip.

As we were completing the management dashboard for this process, I asked the VP Engineering if he would mind if I showed it to others in the company as an example. He offered something better – an opportunity to present the dashboard to the entire company at a roundtable style meeting the engineering department holds. This was a fantastic opportunity to market SharePoint within our company for several reasons:

Real Solution – In the past, we have tried to get people excited about SharePoint by showing example solutions designed to highlight a specific feature. Unfortunately, in those cases, we are always asking the audience to work too hard. We are asking them to understand what we are doing, and imagine how they might map the demonstrated capability to their department. We, SharePoint practitioners, do this all the time, but that’s because this is our job, and we already understand SharePoint. It’s hard for people to juggle an unknown and an imaginary scenario at the same time.

Not an IT Solution – The next worst thing after a hypothetical solution is an IT solution. I have demonstrated libraries, processes, lists and workflows around IT Asset Control, communication with IT vendors and even the way I handle the AIIM New England Chapter minutes. These were all real working examples, but they were all in support of a world my audience still had to imagine. Everyone in our company knows what an engineering inspection is. Everyone has seen at least one inspection report and everyone knows how important the inspection activity is to our operation. When we demonstrated the SharePoint solution, they only had to understand the part that SharePoint was adding to the process.

In taking advantage of this opportunity, we were careful not to mess it up by making it an “IT Thing”. My coworker, the woman who built the solution, was careful to express everything from an engineering point of view. She talked about how the engineers work, and how the Vice President uses the dashboard. She pointed out the benefit they derive from the project. She didn’t use the words ‘workflow’, ‘metadata’ or ‘content type’. OK, she may have used ‘content type’ when answering a question, but the point is, she kept her demonstration in business terms. When we were describing the dashboard, we emphasized how the information being displayed was gleaned from the document library. I may have used the word ‘metadata’ at that point, but I tried to avoid saying it twice. We tried to put distance between SharePoint and the fat-client / database server applications our fellow employees are used to. Yes, I know SharePoint is or at least resides in a database, I even mentioned that to my coworker and we both agreed “let’s not go there.”

Even though the process is largely similar or at least analogous to a database system, there is a beneficial distinction between reporting from SharePoint metadata and reporting transactions. Reporting from SharePoint appears to be a bonus; we aren’t adding metadata as a transactional element so we can report on it. We add the metadata so we can find our reports, so we can organize our reports and so we can manage the process. By manipulating the metadata behind the scenes of a management dashboard, we get additional benefit. You can split hairs and point out that our dashboard is basically the same as a monthly premium report. You may even be right, but as I said at the outset, this was a marketing exercise.