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.

Prototypes

imageOK, so it’s not a piece of fine furniture, it’s a prototype. It serves many purposes and it reminds me of why we sometimes need to build prototypes when developing systems and when deploying SharePoint. Like most things related to systems development, it might be easier to think of this real world example instead of the hypothetical SharePoint example. Let’s think about why my daughter built a foam coffee table.

Raw Material Limitations – A few years ago, my father-in-law arranged for a friend of his to give me a pile of hardwood lumber out-cuts. I didn’t really want this lumber, but the friend didn’t want to see it go to waste, and it was a very nice gesture so I agreed to take it. My father-in-law has since passed away, and my daughter wants to build a piece of furniture from that lumber. It’s a collection of odd lengths and species, so we tore through it trying to identify the limiting factors: What is the longest piece that can be used to make legs, the longest piece that can be used to make the apron, the pieces that might be glued together to make the top. Clearly, SharePoint comes with limitations too. Do we have Enterprise features? Do we have enough storage space? Do we have enough CALs? Building a prototype that is subject to the real world constraints, prevents us from designing what we can’t deliver. We also should consider that constraints can be removed. As we were sifting through the pile of wood, I reminded my daughter that “we can also buy lumber”, but she likes the idea of using only what we have. My boss sometimes likes that same idea.

Expertise and Technical Limitations – In order to turn this wood into a piece of furniture, she needs to perform a variety of operations. For example, the wood has to be cut and surfaced, a process that results in some waste. The legs of the prototype are as wide and as tall as they can be, given the piece she has selected to use for legs and factoring in the effects of preparation. Building the prototype allowed her to put the “table” in her living room and see if it works. SharePoint and the shops that support it are fraught with limitations. For example; in our shop, we limit ourselves to SP Designer workflows. We have Visual Studio, but we try to avoid using it with SharePoint. We also try to handle our SharePoint work ourselves; I have a consulting budget, but I try not to spend much of it on SharePoint. SharePoint is the low-cost solution we chose to reduce the need for custom development and consultants; my job is to keep it low-cost.

Look and Feel – My daughter wants drawers under her table. She isn’t planning to load them up with cans of soup, but she wants to be able to stick a few remotes in them. She wants the drawers to be interesting – she’s an artist, and when artists use the word “interesting” buckle-up, you are in for a journey. We talked about hanging the drawers from the table top with the appearance that they were floating. Of course, we needed to see that. Look and feel is often overlooked when using SharePoint, at least in our shop. I have been trying to pay better attention to this lately, and sometimes that involves mocking up a page that helps the user understand what the solution will look like and how the solution will work. We have been using SharePoint for more than five years, but as I said a couple of weeks ago, people don’t always know what to expect.

A few thoughts on prototyping – When we were building the prototype, I really thought one drawer would be enough. One drawer would show her the size, as well as give her a good idea of how well the drawer could hide the structure (essential to make the drawers appear to be floating). My daughter wanted to build all five drawers. I lost the argument in my shop, but you need to be careful not to lose that argument in yours. Here are a few tips: 1) Avoid over-building – use the prototype to validate the concept, and then move on to real work. 2) Fight the desire to morph the prototype into the final product. While it may sound tempting, it often results in people arbitrarily limiting the creative process, or worse, carrying mistakes into the real world. We will throw away the foam coffee table when we start working in wood. 3) Look to see if you already have a model. Prototypes are great, but showing someone a working solution in another department, or even another company is often better.