Face to Face

clip_image002About 5 years ago we launched a project to give our customers access to certain key documents via an Internet-facing SharePoint site. We worked with a small group of beta users as we developed the site(s) and I gave a short presentation at our Policyholder Meeting later that year. The following year I conducted a training class at our Policyholder Meeting. For the past three years I have offered to meet, one-on-one with our customers to walk them through their specific site. These have been great meetings, but suffice it to say, they are different than giving a presentation, or conducting a class.

When we develop solutions on SharePoint internally, we have our coworkers to bounce ideas off of to help us perfect the design and to test the solutions with us. When we develop for our customers, we have to get it right without a lot of input, without the collaboration features of Lync and sometimes, without the benefit of their having an understanding of SharePoint. An interesting twist this year was the fact that every member of the original beta group is now retired.

I met with about 10 different people. Some were new to their role, taking the place of those retirees and some were relative old-timers. As I walked them through the features of the Policyholder Portal (yeah, I know…portal… well, it’s what we called it 5 years ago, so) they were generally impressed. My goal was to come away from these meetings with three things: happy customers, food for thought and happy customers. I put that in twice because I want them to be happy and my boss wants them to be happy. I also tried to pay attention to their general reaction, particularly the people who were seeing our site and perhaps SharePoint for the first time. I’ll save the specific enhancements I agreed to have my team make for later posts, but let me share the general observations.

Content – We have generally focused our development effort on improving the quality of the content available to our customers. This seems to have been the right play. They were impressed by the fact that they can directly access information that they used to have to ask for. Not that we were ever unresponsive in handling those requests, but the difference between the time it takes to send and receive a response to an email and immediate access is huge. Also, new people don’t always know what to ask for. If you don’t know what content is available, asking for it will consume several email cycles – browsing a site lets you figure it out on your own and that seems to be a very important benefit. In addition, two of our customers expressed an interest in working toward the goal of getting content out of email altogether.

Food for thought – add some guidance to the site to help people know what content is available and how to get to it.

Security – “How are you protecting my information?” That’s a question I was asked several times, and that’s a question that I am asking vendors in my supply chain. After months and months of watching leaks, breaches and spying being rolled out on the news, people are concerned about who has access to information about them. I explained what we do to protect their content, and I explained what we plan to do to improve that next year. They were happy to hear that this has always been a concern of ours and they were happier to hear that we aren’t resting on a five-year-old solution. When I explained that our plan for next year involves moving to SharePoint 365, they were less happy. Regardless of how secure a cloud-based solution is, it involves incorporating more people in that supply chain, and these days, nobody is happy with that thought.

Food for thought – Make sure the SharePoint 365 host we choose understands that security and confidentiality are important critical.

Process – One of the things people seemed to appreciate most was our effort to automate the transfer of content from our internal business process to the Internet-facing site. Automated processes insure that current content will be available in a timely manner. It’s not that our customers don’t trust our staff to do that job, but they like the idea that the process is on rails, so to speak.

Food for thought – Make sure that we can extend that process into SharePoint 365.

I wish I could have beamed a few people from Microsoft into these meetings. I wish I could put them face-to-face with my customers so they could see how important it is for SharePoint to grow in terms of those fundamental capabilities that caused us to buy it in 2006. Marching forward into “new ways of working” is important, but not if it comes at the expense of content, security, and process capabilities or improvements in those critical areas.

Disposable SharePoint

clip_image002I was pretty sure that I have written about this subject before, but I can’t find it so here goes. One of the things I love about SharePoint is one of the most often overlooked features – the fact that sites can be destroyed. When I say “destroyed” I mean exactly that, deleted, eliminated and removed from use. When I say “overlooked” I mean that we are usually focused on building sites to support an ongoing need or to automate a permanent process; I mean that we are thinking long-term or permanent. In our case, it’s because we tend to focus on Content Management solutions as opposed to playing to SharePoint’s strength of collaboration.

This week, we started the process of setting up a new temporary site, just as I was getting close to eliminating a similar site. Both sites were built in support of a systems development effort, and both benefit from several of SharePoint’s out-of-the-box technology.

The older site was built to organize documents related to a major redesign of our policy rating system. We used SharePoint to hold spreadsheet models, sample reports, SQL Select statements, documentation and we even used a SharePoint wiki to design changes to a user interface. We had a discussion list to track problems and potential solutions and we had a task list to keep people aware of pending deadlines. Today, as we are beginning to build out a more comprehensive site for our underwriting department, we are moving the useful artifacts from the development site to a permanent home. Soon, we will simply delete the old site. I must say that I wish SharePoint had some of the features of my daughter’s old game, Kid Cad, which let you delete structures by running a bulldozer through them or by using explosives. Microsoft could have at least added some sound effects to list, library and site destruction.

The new site will be used to help us as we design and develop a replacement for our foreign reinsurance management system. Right now, we are simply providing access to some reports that are being used to verify our data conversion process. As the system grows and as we start breaking ground on design issues, we will likely expand our use of SharePoint. This makes sense for a few reasons.

Proximity – If you’ve been reading this blog for even a little while, you knew that was coming. Having the things you need clustered together is a good thing. People like being able to find everything about a project in the same general area, and SharePoint allows us to quickly assemble highly functional little areas.

Feels Like Home –Yeah, I’m dreaming, but people are getting used to SharePoint and we are starting to benefit from the fact that they generally know what to do to get from A to B and how to get back to A. That may not sound like much, but navigation was a big complaint early on, so either people have figured it out, or they’ve stopped complaining. We have already delivered some reporting solutions to this department in SharePoint, so I think the feeling of familiarity will actually help us.

Easy to Delete – I have been doing systems development for 35 years, and one thing that hasn’t changed is the amount of stuff that gets generated. Not only do we create a lot of tables, diagrams, reports and data, we tend to spread it around, and forget where we put it. I am reasonably sure that I could find documents related to development projects from the early 1990’s if I looked hard enough. When we do tear this site down, just like the one I mentioned earlier, it will go in one smooth motion.

SharePoint sites can be made to stick around and serve future employees, but they can also be built for a single, temporary purpose. That’s one of the good things about this platform. Unfortunately, humans have a tendency to hold a certain pride of authorship that causes us to keep sites after they have served their purpose. We tell ourselves that “this data might be useful someday…” or “we may need to show this to the auditors…” or “we may want to review this when we make the next change…” Those aren’t hypothetical; I’ve said all three of them before. If the site is good, make it a template, and then light the fuses.

This Has to Go – No Wait

imageOne of the amazing things you will frequently witness during the process of automating something is the transition from unconcerned consumer to connoisseur. People who were perfectly happy tossing a bunch of files into a folder on the K: drive suddenly become concerned with the induction, retention and disposition process. People, who were comfortable pawing their way through a bunch of similarly named documents, worry about the effectiveness of versioning. People who were un-phased by using email as the transport layer for collaboration question the reliability of alerts and people who have probably recreated content they couldn’t find obsess over the accuracy of search. The good news is that no matter how unfounded their concerns, the answer with SharePoint is usually “yes you can”, “yes it does” or “we can make that work the way you want!” Our most recent struggle with these questions revolved around the destruction of documents.

There are at least two points in the document life-cycle where a destruction policy is necessary. One is at the end of the retention period, when the document no longer has value. The other is during the creation of major version. We want to keep the major version, but we may need to delete the drafts and / or the prior version. This makes perfect sense, and is easy to understand for any given document, but it becomes difficult when you start thinking about hundreds of documents. SharePoint provides numerous tools to help us through this process, but it also complicates our policy making process. Library settings, alerts and workflows in SharePoint, enable us to implement retention, destruction, notification and even legal holds on content, but they apply to libraries. This means that we have to extend our analysis up-front to the decisions that lie in the future.

“Will all the documents in this library be disposed of according to the same policy?

If the answer is “no” then you need a different library.

The other problem we have to deal with is the standard double-edged sword that is SharePoint, namely that we tend to mix collaboration and content management in the same place. I truly love the fact that we can support a collaborative, iterative content development process inside the library where complex content will be stored. It reminds me of the new construction within the industry we insure, where fabrication and storage facilities have been built proximate to the emerging power plant. When completed, the construction remnants will be removed, just like the draft documents and many of the data sets and spreadsheets that supported the analysis and decision making along the way. However, just like with the documents themselves, these are decisions that have to be made up-front. How many drafts do we keep? How long do we keep them? Who decides when a draft document is published as a major version? How many major versions do we keep?

The real problem isn’t with SharePoint, and, to avoid the faux pas revealed in last week’s post, I will add that it isn’t really a problem. As we work to change the collective behavior of people, we are asking them to give up the control they perceive to be inherent in the current process. People have a sense, however false, that they are in control of the contents of a shared folder, and when we ask them to yield that control to workflows and policies, and they instinctively push back. The fact that I can point to 60,000 documents under a root-level shared folder as indication that the current process is out of control is irrelevant. The thought process says “I can take control of this content at any point” and we don’t see that capability in SharePoint. I can modify the parameters that control the automatic actions, but that is buried beneath the surface; I can’t touch those parameters as easily as I can the documents themselves. In addition, the decisions we make affect all the documents in a library. That is a great benefit, but it’s also a scary proposition.