Plan Faster

imageThat’s the Jack Rabbit pictured at the right. It’s a roller coaster in Kennywood Park outside of Pittsburgh and it’s been rolling since 1920. It has changed over time, but it still offers the basic promise of a thrilling ride. It’s still a very important part of the overall joy of spending a day at Kennywood. I’m sorry, this isn’t my vacation blog, and I do have a point. The world of information management is changing very fast, but we can still keep the whole package viable, if we manage change correctly.

About a year ago, we made the decision to use Citrix ShareFile. I started to explain that a while back, and I promised a more detailed explanation, but I’m not going to provide that today. One reason is that the ShareFile we decided to use has changed. It’s changed quite a bit, as has every other file-sharing service. If I explained the features we liked about ShareFile this time last year, you might say: “you can get 10x that amount of file space today for free!” You would be wrong. You can get closer to 50x today for free if you look in the right places.

That isn’t the point, that can’t be the point.

That could never be the point. You could never make business decisions based solely on price, but you clearly can’t do that today when it comes to file sharing and online storage.

The point, my dilemma, the next IT problem, is that the pace of change is exceeding our ability to plan like we used to. Remember Roadmaps? Remember when the industry leading vendors would tell you what they were planning to do over the course of the next 3-5 years? I do. I remember being able to take those roadmaps, with a few grains of salt, and build our 1-3 year plans from them.

Forget that.

You can’t do that anymore.

We selected a product/service (ShareFile) in October 2013. By the time we explained our plans to use that service to a committee representing our customers in April 2014, it had changed significantly. Now, as we are getting ready to roll out the solution, it has changed even more. It’s OK. It still does what we want it to do. And, the changes are mostly good, or the kind that might be good someday. I don’t have this stuff all figured out, but here are a few things I think we have to keep in mind as we try to hang onto this ride:

Maintain control – You can’t run your business if you cede control to vendors who are fighting for their own survival. You might not be able to specify the details of your plan as it extends very far into the future, but you still have to have a plan.

Maintain focus – If you’re saying “how can I plan when technology is changing so fast?” you might be focused on the wrong thing. You might be focused on the tools. My plan is to support the business needs of our company. ShareFile is a tool that I am using to meet those needs.

Be the buffer – If you think your head is swimming in a sea of technological change, think about your non-technical coworkers. You might be able to (I’m dropping the metaphor before I have to talk about someone drowning) deal with the pace of change, but they can’t. They shouldn’t have to. Remember, they have a day job. Even if you are using a cloud-based solution, you can control the pace of change through the solutions you build.

Avoid kit solutions – I buy a lot of tools, but the ones I won’t buy are the 18-piece battery powered every-tool-you-ever-need kits. I don’t buy them because when the batteries die and the new-fangled batteries aren’t being made to fit that kit, I’ve lost 18 tools. SharePoint might be a kit. I’m not saying you shouldn’t buy it, but we have narrowed our plans to use SharePoint to stay closer to what we think are its core capabilities. ShareFile basically does one thing. It’s a thing we need, so we’re good.

Avoid capital expenditures – One side-effect of cloud-based solutions is a move to subscription fees vs. capital expenditures. That’s a good thing. Large capital expenditures have to work over a long enough time to provide the return on the investment that you made to acquire them. The return on investment ends when those 18 inoperable tools have to be carted to the curb.

Communicate – Even though you can’t introduce change to your coworkers as fast as it’s being introduced to you, you have to change things faster than they want you to. Let people know what you’re thinking and where you are heading. Let people know when your plans start to change. Let them know that you’re managing rapid and uncontrollable change on their behalf.

Buckle-up, keeps your hands in the car at all times and enjoy the ride.

Pardon the Abused Analogy

It’s summer and for me that always means DIY home improvement projects. That translates to short work weeks and limited blog fodder. I told myself “if I have nothing, I’ll write nothing,” but sometimes little things crawl into my head and seem important. This week’s DIY project produced just such a moment. Take a quick look at the three photos below.image

These are from three home improvement projects. The little support structure on the right was required to replace a badly worn outside faucet. It should have been replaced years ago, but having to work in the corner of the burner room, tucked uncomfortably between the oil tank and the main water supply, caused me to put it off as long as I could.

All three are photos of “platforms” – used to literally support the worker. In the early days of SharePoint, we were often quick to point out that “SharePoint isn’t a product, it’s a platform!” Yes it is, but just as all platforms are not the same, we are witnessing the fact that all SharePoints are not the same. Platforms, as those three pictures illustrate, need to be well-matched to the activity that they are supporting. image

At the risk of stretching this analogy to the breaking point, consider that the makeshift scaffold that I stood on while removing and rebuilding this complex bit of plumbing was an “on premises” platform. It was fixed, limited in functionality and accessible only by the “privileged” few or one in this case who were in the room with it. The platform on the left invokes a “cloud” mental image and fits that image quite well. It was flexible, scalable and was easily abandoned when no longer required. The middle platform is clearly (OK, not clearly) a hybrid model; perhaps the best of both worlds but suffering the limitations of each.

Just as none of these physical platforms could be used in all three home improvement projects, no one installation of SharePoint will be well suited to all of our business needs. In some cases, no version of SharePoint might be the right version. In fairness, you can substitute any other product name for SharePoint. As platforms evolve or change or de-evolve by shedding features we used to like, their appropriateness needs to be reevaluated. It can’t be as simple as saying “we use SharePoint so we’ll do what we have to do to continue using it.” Microsoft may like that, but I’m sure my boss wouldn’t.

Will We Ever Get This Right

Almost every IT shop has an inventory of projects. imageSome have been on the shelf for a long time and curiously, some pop into inventory and immediately get addressed. What causes one project to leap ahead of 10 or 20 others? Well, it might be an executive sponsor. It might be a pressing regulatory need. It might be a staffing change. Sometimes, it’s not logical. We are reexamining our priorities this summer for all these reasons. I’ve been at this a long time so I take change in stride. So far, nothing has ever stopped the show from going on.

Ironically, I started thinking about what drives technology projects not from the perspective of a producer of technology, not even as a consumer, but as an innocent bystander.

I had to see a doctor this week. I hurt my shoulder and I needed the advice of an Orthopedic specialist. My primary care physician has recently added an Orthopedic PA (Physician’s Assistant) to his staff so that made scheduling easy. No referral required. Unfortunately, when I sustained a similar injury to my other shoulder several years ago, I was under the care of a different PA who was working with a different physician. Those records were “transmitted” verbally by me during my exam. Later, my wife quizzed me – “did you tell her about the…?” How nice it would have been for all of that information to have been available during my exam. “Oh, it’s in the works” I’m told, but it’s probably a long way off.

Fortunately, this PA did have access to my medical allergies and knew better than to prescribe any form of NSAID in the Propionic Acid class, to which I am allergic. She prescribed a topical gel from a class that those records indicated that I am not allergic to. Yay for accurate and complete, albeit isolated records!

An hour later, I was at the drug store trying to get that prescription filled. The ointment she wanted me to use is not an approved medication according to my medical insurance provider. The drug store has that information because they have access to my insurance provider’s database. They have access because having access allows them to charge me the right amount and get paid faster. My doctor, who might have prescribed something different had she known what was approved, has no such access.

I explained why my doctor had prescribed this medicine. I explained my allergies and how this stuff is in the Acetic Acid class rather than the Propionic class. They, the clerk and the pharmacist, both felt that that explanation would convince my insurance provider to agree to pay for it, but only if it came from my doctor. Not wanting to wait for the wheels of medical deliberation to turn, I agreed to pay the “retail” price instead.

Once the clerk confirmed the price and my willingness to pay the price, she handed the script to the pharmacist who had been at her side during the entire discussion. Before I got to the waiting area, the pharmacist called me back to the window.

Our records indicate that you are allergic to NSAIDs.

Without being snarky to the last human being standing between me and relief from pain, I recalled the conversation we had just finished. I explained again that I appear to tolerate a specific class of NSAIDs and that this gel was in that class. He apologized and then he explained.

I heard your explanation and it makes sense. Our system doesn’t differentiate by NSAID class; I wish it did because this is common. As for making you provide the information again, I am only following protocol. I have to check a box that says you provided this information to me in response to my question about your allergy.”

Oh, it’s a liability issue. If I were to end up in an Emergency Room, this drug store doesn’t want to be in court having their employee say “well, I overheard him say to our clerk that…” I get it.

I get all of this:

Having accurate and complete information helps people make better decisions.

Having access to information can sometimes save money.

Information is good but authoritative information is better.

Protocols are important and should be followed.

I also understand that the systems that exist and the connections that have been made are the ones that either save money or reduce liability. The ones that would merely benefit the people involved are still sitting in inventory. ROI, whether you prefer ‘return on investment’ or ‘risk of incarceration’ can’t be the only driver when deciding what system to build. Sooner or later, we have to find a way to place value on the information that would simply help people do a better job.

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.