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.