SharePoint Joinery

clip_image002One of the challenging things about working with wood is learning all of the different ways that wood can be joined together. As I said a few weeks ago, it’s not like you can weld it. Joinery is fascinating, labor intensive and meticulous work. The goal is to maximize the surface area for glue and if possible, include a mechanical connection for added strength. I know how to make almost every type of joint, but sometimes I cheat.

If you look at the picture to the right, you will see that it features an interesting joint. With a little fancy cutting, I can create the illusion of a door and a face frame in what is really a solid panel. But, if you look down and to the right, you’ll see a pocket screw.

Pocket screws are a wonderful little cheat. No fancy cutting involved. Drill a hole by running a special kind of bit through a jig, add a bit of glue and whirr whirr whirr, screw the thing together. Fast, easy and ridiculously strong, they only feel like cheating to the guy who knows how to cut the other kind of joints. Email is the pocket screw of SharePoint (see, I do know which blog I’m writing).

Apparently, the fitness freaks in our Human Resources department want us to get healthy. We are going to have an exercise contest where we will form teams, count steps and track calories and the winners will get something like a gift certificate at Dick’s Sporting Goods. Personally, I think that’s like dieting in order to win a case of Tofu, but that’s beside the point. The point is, they want to track this all in SharePoint, which is very cool. Even better, the young woman running the contest wants to build the tracking solution herself. Now that’s exercise I can support.

She will be using a couple of custom lists, some connecting gear and a widget or two:

Team Members – I.E. those of us inclined to walk, run, bike, swim or climb our way to a healthy heart.

Teams – Because some people need a better reason to exercise than living longer. For those people, we introduce peer pressure and the fear of letting your friends down.

Steps – Who, when and how many.

Workflows – She has one that enrolls a person onto a team, and one that adds an individual’s steps to the team total.

Widget – Sooner or later, she’s going to want to make this pretty.

Before we get to making this pretty, she wants to make it easy. I like that. SharePoint should be easy. The problem is that she wants us to walk every day! If we have walk on Saturday and Sunday, we have to have a way to record the steps. We have several:

VPN – Fire up your laptop, connect with VPN, go to the SharePoint site and enter your steps.

Mobile Browser – She’s going to make a nice looking mobile version of the entry page and we will publish that through the MaaS 360 browser. That way, people with iPhones or iPads can enter their steps without having to log in. That’s easy.

Email – Email? Yes, email. SharePoint can receive email. SharePoint workflows can “read” emails and I can enter my steps in a dirt-simple process.

To: TheSharePointLibraryAcceptingSteps@ourDomain.com
From: Me
Subject: Steps 06/01/2014 12,500

I’m going to walk a lot in June.

clip_image004That’s easy to do, and with the help of those HarePoint Extensions for SharePoint workflows, it will be easy to build. HarePoint is like the jig that helps me angle those pocket screws into position.

We use email in several processes where connecting something to SharePoint would otherwise require the equivalent of a hand-cut dovetail. For example, we have a process where SharePoint needs to know about a status change that results from a SQL Server stored procedure. Connecting SharePoint to SQL Server is possible, but running workflows on External Lists is not – the data isn’t in SharePoint. Fortunately, SQL Server can send SharePoint an email and we can read that email.

Of course, SharePoint can send email too. So, if one of our employees doesn’t include enough information on the subject line of that email, our workflow can write them back:

Yo, Stepper. We’re thrilled that you’re getting some exercise, but we do need three things to make those steps count. Please include the word ‘step’ (or steps, or Steppenwolf), an mm/dd/yyyy formatted date and the number of steps on the subject line of your email. They can be in any order, but we need all three.

Thanks,
Step counting robot

Sure, there are other ways to connect SharePoint to the rest of the world, but email works well enough in this case. People like email. People understand email. People can send email from almost anywhere using almost any device. Besides, the goal isn’t to show off our SharePoint prowess, the goal is to make life easy. I think I’ll go walk me some steps.

Apparently I am a Dumbass

imageEarlier this week, I gave two presentations in Orlando, FL. One, at the AIIM Conference was well received; it was about SharePoint and ECM and will take a few blog posts to sort out.

The second presentation was to the Service Provider Executive Forum (SPEF) and unfortunately, it’s very easy to describe. The vendors attending SPEF are the ones who sell scanning services, document storage, printers, copiers and scanners. SPEF was one of those conference-within-a-conference deals, and my presentation was part of a ‘User Feedback’ panel.

I worked hard on this presentation. It was a good presentation. It just wasn’t the message this group wanted to hear. I’m sorry for that, but I don’t have a great history with this industry. My message wasn’t a feel-good story. I talked about why we don’t use many of these services, and how our most recent encounter has gone somewhat off the rails. I had hoped that the organizer was right when she told me:

They will appreciate your candor

Here’s a tip: if you ever hear those words, run. Drop everything, don’t tweet about it, don’t snap a picture, don’t think twice – just run.

Our story in a nutshell – we are small. This industry’s story in a my-opinion-nutshell – they are commodity brokers seeking a sale at any cost.

The best analogy I can come up with is that buying these services or products is like buying a digital camera; they all take pictures, they all have good battery life and they all let me move pictures to my PC, tablet, Cloud storage, etc. Once I decide the few, somewhat unique features (zoom, video, and form-factor) that I want, it comes down to picking the one that’s most comfortable.

The problem – that we have experienced – is that some salespeople want to be the mystic swami in your life. They don’t want informed customers. They don’t want to hear your story; they want to tell you theirs.

My presentation carefully presented our position, our real-life experience and then I took “questions” I put that in quotes because most of what I heard were not questions per se.

Why didn’t you buy a scanner? Scanning to SharePoint from dedicated scanners seems to provide more robust options than scanning from multi-function copies (MFCs)…who knew? More importantly, who cares? The fact of the matter is that we don’t have a space for a dedicated scanner, nor do we have the volume to justify one. In addition, we only want to have to learn how to use one device.

Why didn’t you do an RFI first?  Seriously, an RFI for two MFCs?

You’re ignoring the money you could save by outsourcing all the scanning to us. I reminded this person that I had explained the very, very high cost of teaching someone how to classify and index our documents.

Finally, a white knight emerged. Addressing the audience, he said:

What I’m hearing is that you guys are saying that Dan is a dumbass

Ah…well…thanks?

His point was that I failed to engage with them according to their preferred sales method. Apparently, from their perspective, that was my mistake.

One woman came up to me afterwards and said “I don’t think you’re a dumbass, but this managed metadata thing sounds like a unique requirement.” I reminded her that it’s a mainstream feature of a major product. I didn’t invent it; I just want to use it. More importantly, it was a written requirement that we were willing to explain.

One guy followed me to my next presentation, all the way telling me that if I had done an RFI he would have been able to explain why we needed a scanner. I explained, again, why we chose MFCs over a dedicated scanner.

He turned up again later as I was boarding the bus to the conference social event. He started telling me about the features of the scanner. The one we don’t want – as if he thought that if he gave the same pitch often enough I might just buy one. My friend (who sells a high-end ECM product) said:

This guy sells hammers. You have a screw, but he still has to try and sell you a hammer.” He added, “It’s a sales technique we call show-up and throw-up.”

I’ll leave you with the message in my final two slides. When we look for vendors to help us, we look for a vendor who will:

  • Be a business partner with us
  • Let us do the portions of the project that we feel we need to closely control
  • Accept that we know our business and know enough about yours to evaluate you/your product or services as compared to others that are available
  • Think long term; think beyond this sale and this commission.

Oh, and don’t lie to me. I can handle the truth.

Divide and Conquer

imageWhen I was making the coffee table that sits in my office, I learned a lot about bending steel. Specifically, I learned that bending square steel tubing isn’t easy and often doesn’t end well. Some bends were wide enough that I could negotiate the turn and repair the damage, but others were just a bend too far. For those, I took it in steps: cut, bend a little, cut again and then weld back together. I thought about that process this week, as I struggled with a workflow issue. I’m not sure if this is a common issue, but it seems to come up for us quite often:

“Is it better to build one big, ugly, complicated workflow or is it better to create a few additional lists and spread the work across them?”

We almost always tend to spread the complexity around. In the solution I’m working on today. I need to accomplish three major steps in order to reduce a 12-15 page Word document into a series of entries in a custom list:

  • Parse all of the recommendations out of the Word document
  • Determine if the recommendations are New, Open, Pending or Closed as of the date of this report, and
  • Create entries into either a custom list of recommendations or in a custom list of updates to existing recommendations.

All of this can be done by a workflow, but it’s a complicated task. A single big ugly workflow would need to keep track of individual recommendations, whether they are new or some other status and look up the details about the inspection report metadata and copy it into the other lists. I opted for a process that involves two additional custom lists:

One is a list of what I call “splits.” Splits are the big chunks of parsed text. All the new recommendations are in a split. Likewise, all the pending recommendations are in a split, and so on. A workflow that runs when the splits are created doesn’t have to determine what kind of recommendation it’s dealing with, they are all new, or pending, or some other status.

That workflow parses all the recommendations into individual entries in the second list. That list is then built up of individual recommendations which have a status (new, pending, etc.) and all the metadata that they need to be transformed into an item in the ultimate destination list. A final workflow that runs as these items are created takes care of dispatching those items.

The cost of this solution is the creation of a couple additional custom lists and a bit of duplication of data (although the items in these intermediate lists can safely be deleted). The benefits include:

Easier to plan – The overall process is easier to plan and stage. The process becomes a fairly simple routing exercise. Big boxes of the same thing arrive at one list where they are opened, separated and distributed to a second list. It’s like a wholesale-to-retail operation.

Easier to build the workflows – Rather than a complicated workflow with lots of variables and lots of steps, I have three single-purpose workflows that are each of a manageable size. I built the process in discreet steps, only moving forward once things are working at each level.

Easier to control new vs. update action – By the time I need to know whether to create a new recommendation or an update to an existing recommendation, the list item I am working with includes that information as well as everything I need to create those items.

Easier to debug – This is a big deal for the developer (me). As I am configuring these workflows, there’s really only one way any of them can fail. That is so much easier to deal with than a workflow that can fail any of three or more ways, especially given the current state of SharePoint Designer’s debugging tools.

Easier to rerun – Some of the workflows trigger alerts, some set metadata in other lists and change the status of other processes. Working in smaller segments means there are fewer things to fix if something ultimately goes off the rails.

It might be tempting to just keep on grinding out steps in a single workflow. However, dividing the steps into logical groups and taking advantage of storing partially processed items in interim lists is a very powerful concept. This approach makes design and development easier. By the way, it worked for that coffee table too. If you want to read more about that project, take a look over here.

Baby Needs a New Pair of Shoes

imageSometimes you get a little beyond peoples’ ability to imagine when you start describing what, as far as you’re concerned is a simple SharePoint solution. It’s not hard. Depending on how often your audience has been exposed to SharePoint, their ability to imagine might be quite limited.

That is not their problem

That is your challenge.

We are facing this challenge right now, and we are going to work through it by building a straw man solution. If we are lucky, we will roll a 7 (since many of you just returned from Vegas) and we will be able to continue building from our first result. If we are not so lucky, we will roll an 8 and we will be able to continue to roll and maybe work our way into another 8, at which point everyone wins. If we totally miss the boat, we crap out, we tear it down and we start over. If we don’t go nuts, if we don’t spend a lot of money, if we don’t invest a lot of time, none of those options are going to make me cry. Keep in mind that I am not the one building the solution that we might tear down so someone on my staff might cry a little.

Why would I do this? Why don’t we just ask people to trust us? Why don’t we draw a bunch of illustrations in Viso and PowerPoint and make them sit through a boring presentation full of buzzwords and jargon and technobabble that none of them will understand? That approach has worked in the past…hasn’t it? Oh, right.

To keep my customers happy and prevent my people from crying, we had a meeting to discuss the approach. We reached an agreement with the manager of the business unit that we will be working with and we established a few key assumptions about the solution and our approach:

Assumptions – The process will require support in the form of a site on our on-premises SharePoint server that will house critical support content and historic content and business records. The content deemed critical for operational support will be replicated in a SharePoint Online site. The stuff that is so critical for operational support that we just can’t risk ever being without will be included in an iPad app.

If you’re wondering why we don’t just move the whole shooting match to the cloud, there are two reasons: 1) Bits of the historical information processing relies on add-on products that aren’t fully in the cloud yet, and 2) We’re scared. OK, we’re not scared but some people are and we think that asking them to take baby steps is better than asking them to run a marathon.

If you’re wondering why we don’t just point the iPad at the SharePoint online site, there are two reasons: 1) Bad things happen. During the snowstorm in 2011, we lost power for 10 days and cell service for 3 (we did have a working land-line phone), and 2) We want a dirt-simple process and nothing says simple like pushing a few buttons on an iPad.

If you’re wondering why we aren’t using a different brand tablet, one that might work better with SharePoint for example, well lets’ just say that we aren’t and leave it at that.

Straw Man – We have agreed to focus on one library that we know will be included in any solution that anyone involved could dream up. We will replicate that library in SharePoint Online and we will wire up a quick and dirty workflow to keep the in-house library in sync with the online version. We will also create a one or two tab iPad app that will include the information that is related to the content in that one library. The manager of the customer department likes the approach. We will show the straw man to everyone else involved in the project to help them better imagine the nature of the full solution. We have an agreement, we will tear this down and start over if we have to, but we don’t want to do that twice.

If you know me, this post might seem a bit out of character. I like prototypes, but in the past I have always said that prototypes should be disposable. This won’t be a prototype, this will be a gamble but it’s a risk I’m willing to take.

Happiness is…

imageRealizing that the thing you need your coworkers to do in order for your SharePoint solution to work, is something they already like doing.

Yeah, that was too long for a title, but that’s how I feel right now. It’s as if my doctor had told me that “in order to remain healthy, you need to eat more Heath Bar Klondikes.” In addition, my new found happiness reveals one of SharePoint’s often overlooked strengths. Yes, if you want to, go get a Klondike before reading; it’s ok.

The project that I’ll be working on while my coworker and friends are in Vegas is one where we hope to link several aspects of our engineering process. To do this, we needed to refine an identifying number that has been in use forever. To really achieve that value we are looking for, we need a way to make it seem like this new way is the way we’ve always done things. The really cool thing is that SharePoint can make this all possible.

I’ve talked about bits and pieces of the neighborhood in which I’m working before, loss control inspection reports, recommendations and composite views of data. We have a solution that lets us track and support the development of a loss control inspection report. Ultimately, that process ends with the final report being stored as a PDF, in a records library – locked away forever. However, the process leaves the Word document that created the PDF, behind for review. Keep that in mind.

We also have a solution that tracks the recommendations our engineers make in those reports. These ‘recs’ have a long and complicated life. They get written. They get reviewed. Customers comment on them, engineering peers comment on them and once or twice a year, they get ranked:

  • How important are they?
  • How are they being addressed?
  • Where are they in that life-cycle?

We built a series of custom lists to aid in this process. We also built a couple of composite pages, aided by some data view web parts to assist in that review. Still, something is missing.

What’s missing is the link between the reports in which the recs originated and the recs and the rec-review process. My job is to establish those links.

This is where ECM projects often run into trouble. We have hundreds of reports. We have hundreds of recommendations. Most of the recommendations are ‘closed’ but they still have value. A lot of information is coded into those custom lists, but the real value, the mother-load of information, is in the original reports. The trouble is that this isn’t a one-and-done process.

The recs can appear in many reports over time and any single report can refer to multiple recommendations. It takes time to review, reread, search and add metadata to those reports in order to link them to the lists…or does it?

Well, it seems that it will take some time, but not much. It also appears that going forward we can keep the reports and the recs in sync, with little or no effort at all.

The key to my happy day lies in the fact that SharePoint, with the aid of some workflow add-on products, can read those reports. Further, it turns out that the way our engineers like to write those reports, their “style,” the style they’ve been using forever, lends itself to being picked apart by Regular Expressions.

The reports already have metadata that tell us what policy they refer to. The recommendations have an ID number that tell us what facility they refer to. Today, I built another SharePoint custom list that links those facility ID numbers and our policy numbers. Now it looks like I’ll be able to have a workflow read the reports, pick out the recommendations and automatically maintain the activity in the recommendation lists. If this is successful, once an engineer finalizes a report, a SharePoint workflow will create a stub new recommendation or a stub recommendation update item, and then create a “please complete this item” task.

I’m talking in the future because I’ve only completed the proof-of-concept steps. I can read the reports. I can find the recommendations. I can build a new composite identifier and I can stick it in every custom list where it’s required. I usually wait until I have a solution to write about it, but this was so much fun, I needed to share it. When I finish this project, I’ll let you know how it works, in this blog and at AIIM14. If I fail or partially fail, I’ll write about that, too.