Plan Faster

That’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.

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.

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. Some 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

When 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.

Forget the User – Think About the Next User

If you know me, or if you know my history, you know that I haven’t always placed an emphasis on “user experience.” I was more concerned with just making things work. Then I met Jill Hart at iPhoneDevCon and I got religion about user experience. I took a class taught by Bob Larrivee and I realized that you can and should design ECM solutions with people in mind. I met Marc Anderson and I learned that there are tons of ways to make SharePoint user friendly without slowing down the development process. I mention these people, not so much as a way of dropping popular cool names in the opening paragraph, but to pay them homage before making a statement that they might be tempted to beat me with.

Forget about the user; make the solution work for the organization!

I can hear my friends groaning. I can hear them saying “no Dan, you can focus on the organization AND the user” and I can almost see them shaking their heads.

I’m not trying to go back to my “make it work, make it fast and then make it pretty” roots, but lately I find myself worrying that the pendulum has swung a bit too far in favor of the user. Specifically, there is a fine line between a great user experience and a solution that is built for a specific user or a specific group of users.

Today people are getting used to having the apps they want, having them now and having them on the cheap, but we can’t afford to treat them like Congress. We can’t let them have their way at the expense of the greater good. Now, in case any of my coworkers are reading my blog, I’m not talking about you, I’m talking about, you know, that other guy. But, if I were talking about you, I might ask you to step back and stop thinking about our project in terms of the way you want this solution to work. Think about the way it needs to work. If I were talking to one of our consultants, I would ask them to stay true to the fundamental best practices that they have built their business on, and remember that they are here to add value to our situation even if their recommendation is a bitter pill. (OK, I think I used enough clichés in that sentence). If I were talking to the members of my team, I would remind them that we aren’t in a popularity contest, but that we have a job to do.

SharePoint is the foundation on which we build our solution. In building that solution, we need to create a viable and sustainable structure that can support the business process going forward. If you’re tired of trying to figure out the metaphors, I’m talking about having the right libraries, the right metadata and automating the right processes to the right extent. I’m talking about taking a hard look at the content we have and working hard to organize it in a way that makes sense. Once all of that is in place, go ahead and make it pretty. I’m fine with pretty. I like pretty (who doesn’t like pretty?), I’ll build pretty things. What I won’t do, is build a solution that is pretty but makes no sense. I won’t build a solution that embeds “the way we’ve always done things” into what is supposed to be a forward looking project. I will build solutions around the right way to do things, but I won’t build them around the way you want to do things (unless those are the same things).

Caveats, clichés, parenthetical expressions, disclaimers and explanations aside, the bottom line is we all have a responsibility to do the right thing as we commit our company’s information to a repository that our successors will have no choice but to use. Let’s get this right and then let’s make it pretty.

The above blathering rant is not based on any current projects and the references to people or people-like entities are not meant to represent my current or retired coworkers. This is all based on things I’ve heard, read about, imagined or things I remember from previous jobs.

Things to Avoid

Earlier this week, we had a meeting about Governance. Now this is usually a painfully boring subject, but this meeting was very productive. We had it at the right time, while we are still in the design phase. Everyone involved with the project was able to attend the meeting, and we had a representative from Legal to give us those all-encouraging nods and to ask the questions nobody else wanted to touch. We had some fun at my expense, when I inadvertently said “we don’t need a better process, we need better people” – sometimes I should just think these things. In the end, we arrived at a good understanding of what we have to do, what I meant to say, and a short list of tasks.

One of the things the group asked for was a list of five things they shouldn’t do. In other words, the Top-5 behaviors we are trying to change. We discussed some of these during the meeting, but as soon as the question was asked, I thought “oh, that’s my blog entry for Saturday.” Here’s my list; your mileage may vary.

Email documents for review – When documents are being managed and stored on SharePoint (or any other ECM platform), keep them out of email. There are several reasons for having a third-rail (don’t touch that) policy here, but these are the biggies:

• Fragmentation – as soon as you send a document for review, instead of sending a link, you are compromising the collaborative process. Conversation becomes binary, and even if you make the suggested changes, they are now attributed to the wrong person.
• Discovery – Who deletes email? If your policy says “all our stuff is in SharePoint” and the discovery operation reveals copies elsewhere, the discovery process is certain to expand.
• Reference – A year from now, the person you sent that email to is more likely to search their inbox than they are to remember to go to the library for the current copy of that document.

Email documents to yourself – We are all guilty of this. It seems like such a convenient way to avoid having to open a VPN connection and wait for documents to load over the net. When you consider that you have to log into your personal email and download the document from there, you must realize that there is virtually no time savings. Logic rarely prevails in these meetings so I relied on fear. Send that document to your personal email, download it to your own device and get ready to turn those devices in if there is a discovery operation.

Version comments = “minor changes” – This is a pet peeve of mine, since I orchestrate the production of a few version-controlled documents that are built via a collaborative effort. Version comments should guide us to the version that we want to open in the event that we have to start digging. There is nothing worse than looking at five drafts, where all of the version comments are meaningless. When you think of the reasons that you want to open an earlier draft: “this was better when it said…” “I liked it better before we reorganized it”, etc. you will be led to make appropriate comments. It doesn’t have to be an essay, but it should be more than filler.

Skip the metadata – Nobody wants to have a library where every metadata field is required, but when metadata is optional, it shouldn’t be avoided. Even if the metadata is required, I’ve seen people avoid the process by putting the document into Shared Documents or some common library with the thought “I’ll move it later when I have more time.” Metadata is there for a reason. If the reason isn’t a good one, if the metadata is unnecessary, redundant or ambiguous, talk to the people who designed the site. If the metadata is important and useful, take the time to fill it out.

Reuse old documents instead templates – I didn’t put this list in order of importance, but this could easily be the most important. I was aided in our discussion of this topic by the fact that the victim portrayed in an earlier blog entry was in the room. I told the story of how he was dragged into a confrontation over a report he had nothing to do with. He had written a good report on a similar subject, and someone decided to use it and simply change the names, dates and facts. There are so many reasons to start with a template and simply copy in old useful content, but clearly establishing the fundamental metadata elements as well as the current approved look and feel rank near the top.

This isn’t a rant. The fact that they asked for this guidance is encouraging, and underscores the sense that we are all Information Professionals.

People Want Different Things

I spent much of this past week in Dallas. My first stop was the AIIM Board meeting that I was invited to attend as an ‘on-deck’ director. My term officially begins on January 1, 2013, and all I can say is that I’m going to have to work hard to participate effectively; this is one impressive group. Immediately following the Board meeting was the AIIM Executive Leadership Council meeting which focused on Big Data. I’m not going to talk about those meetings, but I want to talk about the hotel. I stayed at the Hyatt, which is attached to Union Station where the meetings were held. In between these two buildings, as you might expect are the train tracks. Some people complained about the noise, but I love listening to trains. Even when I woke up in the middle of the night to a train whistle, I woke up with a smile.

Clearly, people don’t want the same things, and it should be just as clear that that fact applies to SharePoint. Several years ago, I created, used (blogged about) and tried to market in our company a template for a SharePoint site for complex projects. This template worked really well, on the two projects where I was involved, you know the guy who likes to listen to trains at night. Only a few others ever used it. The reason was that even though I tried to make the template generic, it had an IT spirit and most people found it to include a lot of things that they didn’t need. People come to SharePoint to do a lot of things, and we have to approach these things differently. The most popular three reasons people come to SharePoint in our shop include:

I don’t care – I would guess that perhaps half the content we have on SharePoint falls into this category; people know it needs to be saved, but they don’t really plan on actively using it. In building this type of site, we focus on how the people work, so we can make the process as painless as possible. If they receive a lot of documents via email, we need to make sure they have Harmon.ie and that they have the libraries setup. If they are going to be pulling scanned documents in, or moving documents from a file share, we need to provision the helper utilities that we have to help them do that. On these sites, we try to organize our way around metadata. By that I mean let the site/library structure direct people to the content and only add a bare minimum of metadata.

I need this to do my job – This is usually some form of transactional or near-transactional content. When we build these sites, we focus on process. By that I mean we look for ways to add workflows to handle required or complicated tasks. We also look for ways to build dashboards or analytic web parts that will give the people interested in this content some insight into the current conditions. We also are starting to focus on making sure we have a nice looking and functional mobile site so that they can do their job from wherever are and when they want to work.  These are sites where a bit more metadata, and a bit more thought about process improvement can pay big dividends later. One of the critical processes to consider automating is the final disposition of content. If, for example, at the end of the process there is a document that needs to be archived, create a workflow to do that. Your users are at the point where they are otherwise done using that content and they are ready to move on – make it easy for them to do that.

I’m doing this for the children – This is an expression that we use in the New England Chapter of AIIM. As we figure out the best ways of doing things, the best caterers to use or the best venues in which to hold our events, we are documenting these facts for those who follow. The focus expands beyond content management to include knowledge transfer. These sites require a lot of thought, particularly when it comes to metadata. Where possible, we are working to use managed metadata or site columns and we try to make good use of content types. Beyond that, we work hard to suggest metadata that will enable findability and support search.               

People use SharePoint for different reasons, but they all want the process to be simple. Einsteil said “make things as simple as possible, but no simpler.” It turns out that he also knew something about trains.

Designed for the Future

In the course of a couple of disjointed weeks, we have been building a new entryway to our house. The small addition features a single level deck, set just below the threshold, and is connected to the driveway by a ramp. A ramp? That seems to be the reaction from most of the people who hear of this project. Yes, a ramp. There are several good reasons to build a ramp now: First, we can; I mean if something were to happen so that we would need a ramp, chances are good that same thing would preclude our building it. Yes, there are volunteer groups who would build a ramp for us at that time, but their focus would rightly be on utility, not appearances; we want the ramp to compliment the house, not detract from it. Second, even if we don’t need it, others might benefit from it now. Third, there are times when healthy people could use a ramp; both my wife and I have spent time on crutches, and this would have been nice to have during that time. Does this sound like SharePoint? It should. Taking the time and spending the money to help SharePoint survive its own success makes good sense. Here are three things that we’ve done that fall into this category:

Separate Content – One of the bits of future-proofing we decided to tackle when we upgraded to SharePoint 2010 was to split much of our content into separate content databases and site collections. We did this where we had to, where individual or combinations of content were banging up against those recommended limits, and we did this where we might have to in the future. There are some immediate benefits, mostly associated with backup and recovery planning, but it’s nice to know that content can grow at its own pace. It’s also nice to know that the navigation we put in place during that upgrade will remain useful for a while.

Domain Names – Changing the location of content presents a problem for users who have bookmarked certain pages. Internally, we are able to address this pretty quickly, but on our Internet-facing server, this had the potential to be a major problem. First, we have many more users hitting that server than the internal one and second, they are scattered far and wide. Rather than issue an apology along with a slightly revised URL, we introduced a new feature – custom domain names. Instead of http://blah.blah.com/policyholders changing to http://blah.newblah.com/policyholders we decided to spend $8 and just make it something like http://www.ourPolicyholders.com. As long as we continue to fork over the registration fee, our users will never have to worry about broken links.

Usability First – Although it’s a bit more nebulous and it’s a change that is occurring at a glacial pace, I think this change has the greatest potential to do good. We have started to slow down the process of building SharePoint solutions so that we can think about, and force our coworkers to think about the design issues that will surface when plans succeed. Library structure, metadata, navigation, and reporting are all aspects of SharePoint that are harder to change than they are to build. We have learned, in some cases the hard way, that it is much better to consider these issues up front and design the site accordingly. We are building a site right now that incorporates a lot of this type of thinking. We have included libraries that have very few documents today, but which will grow to a point that will justify a separate container. We have lookup list metadata columns that are tied to custom lists that the users can easily maintain because they can’t think of every term today. We are adding site-columns that we can use for search terms so that we can put content where it belongs but find it across the whole site structure. We are building parameterized search web parts that will look pretty silly at deployment – they might only return one or two documents but will look fantastic as their results grow automatically over time.

Splitting content into separate site collections does require some additional attention to navigation (you can’t walk all the way back up the tree). Domain names, even at $4.99 a pop add an incremental bit to the ongoing cost of SharePoint. Focusing on usability slows down the development process, but all of these things work to make life easier in the future. Also, just like the ramp, these are all things we can do now, that might be harder or more expensive to do in the future and they all offer some immediate benefit.

A Week Off

I took this past week off to build a combination entryway landing and walkway at our house. I figured that by the end of the week, I’d have a nice analogy between a small construction project and building a SharePoint site. Of course my construction work was delayed by Hurricane Sandy, and when our office lost power, I started thinking about the value in having certain essential content available in a Cloud-based ECM system. Fortunately, if I ever move in that direction, I have a good start courtesy of a timely article by Cheryl McKinnon on CMS Wire. Getting back to the construction analogy, I think that there are some clear common threads between building a physical structure and building something in SharePoint.

Foundation – Every construction project builds off of a good foundation. In the case of our landing, it was a series of six 10” concrete piers, each extending 42” down to get below the frost line. I could have saved myself some back-aching labor and tried to connect the structure to the roof piers that were already there and the side of the house, but that would have meant possibly compromising the piers and affecting the design (see below). We made similar decisions when building our SharePoint site. We could have handled both our internal and Internet users with the same server. That would have saved time and money, but it might have compromised security and it would have meant that trade-offs would have to be made for many internal solutions. We opted for the more expensive approach of having two farms, one internal and one Internet facing, and that has proven to be a very good solution for us.

Proper construction techniques – Although this landing isn’t supporting anything other than a few people, and perhaps a package delivered by UPS, it has to be built according to the building code. Sometimes I wish there was a building code for SharePoint, because people shouldn’t be allowed to build SharePoint badly. When we meet with people to discuss the site they want, we often propose building more than they wanted. We want them to include metadata, we want them to utilize managed metadata when it exists or build it when it would help others. We want them to think hard about whether they need a site, or a library or a folder. We ask them to think down the road to the point where their site has an abundance of content and try to imagine how future users will find what they need. We help them decide what out-of-the-box parts to use the same way the guy at Kelly-Fradet helped me decide what fasteners to use for the Trex decking. When there isn’t anything in the box that meets their needs, we help them build the part that meets their requirements – if they aren’t capable of building that part; we supply or bring in a professional.

Appropriate design elements – The early (and easy) plan to use the existing piers and anchor the landing to the house would have meant cutting into the vinyl siding for about 8’. Whenever you do that, you expose your house to the elements. Of course there are ways to guard against infiltration, but the best way is to not make that cut. When visiting my brother earlier this year, he showed me how his deck comes close to his house, but doesn’t penetrate the siding. That means that although in the course of 25 years a few deck boards rotted, the siding of his house didn’t. Not only does that make sense, it looks much better. When building a SharePoint solution, you have to think about the design while you’re building the foundation. I’ve seen many sites where, after the solution is built, people say things like “I wish it looked better” or “I wish we could look at this…” The time to make those wishes is before you start building.

Sandy cut 3 ½ work days off of my 8-day schedule. Not only did that leave me with a few long days, it meant postponing the walkway section of the project. That’s OK; we can work around that by deploying the two sections in two phases. Our work in SharePoint often follows a similar path. For example, we built a document repository, put it into production and then went back and built a management dashboard several months later. Like home improvement, SharePoint is easier to build right than it is to change later. Getting it right the first time, even if it takes longer and costs a little more is well worth the effort.

No Train Wrecks Allowed

Earlier this week On several occasions this past week, we were trapped inside a Mobius loop of inactivity due to failures of network equipment that resulted from the failure of some AC equipment as well as ill-timed changes to our DNS servers. Having tossed most of our technology eggs into the network basket, we limped along without phones, email, SharePoint and even access to our shared folders. Of course, we have contingency plans, but at what point do you pull the trigger on a change that requires relocating people? I can’t answer that, but I know it isn’t an amount of time that is measured in hours, unless something has been destroyed – enterprises, even small ones, just don’t move that fast.

I am counting on Microsoft to understand this fact about enterprises. Consumer pressure to respond to social, mobile and usability issues aside, they can’t expect to drag corporate America behind them at warp speed. The enterprise will turn about as quickly as the Enterprise. As we sit here today, looking at Windows 8, SharePoint 2013 and the next version of Office, we are in no hurry to adopt any of them. Sure there are machines here that are already sporting the Metro soon-to-be-named interface, but they are R&D items. In the past, we have been among the early adopters of new technology, but this time, we are likely to drag our feet – here’s why:

Mass – Despite the recent wave of annoying technical problems, our current configuration works pretty well. SharePoint, Lync, Exchange, SQL Server, and a whole bunch of systems that use those technologies are humming along. Those systems are talking to each other, and people are getting work done. Most of the job descriptions in my department include references to “staying current” and “researching emerging technologies” but the core requirement of every position’s job description is one that deals with “maintaining technology that is critical to company operations.” Watching over the past week as people lost phones, Internet access and email, I was reminded as to just how important that requirement is. The next generation solutions don’t only have to be released to manufacturing, I need to know that they all work, that they all work together well, and that they support our installed base of software and solutions. Given the speed at which Microsoft is remaking everything, I’m thinking we might not get to that one-big-happy-family state until a bunch of Service Pack 1’s are released.

Motion – Projects don’t stop when new releases are announced, even when the new technology will impact the solution being developed. For example, we are working on a SharePoint-based solution that is using the Mickey-Mouse method of enlisting workflows associated with multiple lists to iterate over the items in one list. SharePoint 2013 is said to support loops in workflows, but that doesn’t mean that we are going table this current project until we are on SP2013. One reason is that I don’t know if the way SharePoint will support loops will do us any good. A second reason is, I wouldn’t be surprised to see the feature get yanked out at the last moment. Finally, I have users waiting to use this solution. We may tweak our design to make it easier to change our workflows once looping is available, but for right now, it’s full speed ahead.

Here’s an example of how mass and motion combine to create momentum: prior to Microsoft announcing their upcoming slate (no pun intended) of tablets, we standardized on iPads. By standardize, I mean we put one in the hands of 2/3 of our employees, so that’s the mobile platform we have to work with through 2013. We have promised those same people a very specific app later this year, and I am still planning to build that app in xCode.

Planning – Microsoft might be reluctant to give me a roadmap that extends past the end of this year, but I have to give my boss one that stretches well into the future. In addition, I have to complete my 2013 budget request within 45 days. It was this time last year that we decided to buy those iPads, and when I think back, I didn’t see any reason why I should have made a different decision. So, looking ahead, I see continuing progress on using SharePoint to help us manage digital content and to improve the effectiveness of certain business processes. Our plans are based on what we know we can deliver during 2013. I stopped writing lists of accomplishments that begin with “due to the later than promised release of…” a long time ago. Our hardware, software, storage and bandwidth budgets will all be predicated on what we know (in September 2012) will happen in 2013.