CT River from North End Bridge

Whenever I give a presentation, I like to think that I have a huge advantage over Microsoft employees and SharePoint consultants. In the first case, I can freely talk about the things SharePoint doesn’t do well, and the things I know it could do better. In the second case, I can talk about the things I don’t do well – I don’t have to try to impress you with my prowess so that you might hire me. I do sometimes worry that if my boss actually reads this blog, he might wonder “why the heck did I leave this bozo in charge,” but I recall that he was the first to identify the therapeutic effect of blogging, so he won’t hold it against me when I air the laundry.

The one consistent truth in systems development, ECM solution development or just about any development process that involves people is that things go off the rails from time to time. I have been building solutions that change the way people work for 35 years, and I have seen just about every reason why solutions fail, from sabotage to resistance at a level that would confound the Borg Queen. I’ve seen solutions that are as good as the technology would permit, as good as the budget would permit, and/or as good as the deadline would permit, but were still not good enough. I have also seen solutions fail because the infrastructure they were built upon evolved in a different direction. None of this is happening today in our case, because our system isn’t failing, and my experience tells me that it isn’t about to fail. Our system is just waiting to be “the way we do things.” Right now, we are still fighting the memory of “the way we’ve always done things” and that is one tough battle. You may have noticed that I haven’t described what went wrong to inspire this blog entry – it doesn’t matter. In fact, if I tell you the questions we were asking as this week ended, I’m sure you will recognize them:

  • What is so hard about this?
  • Why didn’t they tell us they were having this issue?
  • What made them think that (the workaround) would help?

Then we asked the most important question of all – why aren’t they learning how to work with this process?

When we build information management systems, we like to think that we are improving a business process. That’s a comfortable way of looking at development because it creates an abstraction layer between us and the people involved. Considering the business process allows us to ignore history; we don’t care why they “used to do it this way”, we just assume it was because they didn’t have our solution. We aggravate this situation by assuming that everyone wants every process to be as efficient as it can be. We know better. In reality, we are trying to change the behavior of a group of people, and in general, people don’t like change. When things start to go wrong though, we tend to skip past the abstraction layer and zoom in on the people involved. One of the common complaints that I hear about people, when I talk to others in this industry, is the so-called generation effect on technology adoption. People will talk about how much more willing younger people are to embrace new technology than the old guard employees they are being trained to replace. While there certainly are generational differences when it comes to affinity for technology, we also have to consider that new (younger) employees are learning the process and our solution at the same time. In the absence of a historic regimen, any solution that gets the job done has a certain appeal.

As we consider our final question, we have to consider the answers our users aren’t giving us. Nobody is going to just come right out and say “I don’t want my job to change,” but they don’t want their job to change. We can take the Borg Queen’s approach, and remind them that resistance is futile and that our solution is here to stay, or we can step back and look at the new solution from their point of view. How did the system we just build impact this person’s job? We tend to focus on the things we made easier, but did we make anything more difficult? Resistance is futile; in time, people will adapt their behavior to accommodate the requirements of the new process, but what if we missed something? What if that new process could actually be a little bit better? When we see people pushing back, instead of embracing our solutions, we need to try and discover the underlying reason – maybe it’s something we can fix.

Great Ideas Come From Customers

clip_image002We spend a lot of time and considerable effort managing an Internet-facing server for our members, customers and business partners. Usually, this is a “build it and they will come” type effort. We build out what we think is an effective site, we track a certain amount of usage that tells us it’s working, we pat ourselves on the back and move onto the next task. In the course of normal business, we don’t actually have contact with these important users. Recently, I attended our company policyholder meeting, and I got to spend some time in one-on-one meetings with a few of our customers. It’s one thing to send someone their user credentials and receive a “Thanks, this looks good…” email. It’s a whole ‘nother thing to sit next to that person and walk them through their site.

I always get a little nervous before these meetings, and I always come away realizing that the nervousness was unnecessary. We are providing a service to our customers, and they appreciate it. If they have problems, suggestions or questions, they really appreciate the fact that we are willing to solve, consider or answer them. We had a few of each to deal with this time, and I learned a lot in the process.

One of the things that I learned is how important it is to consider SharePoint from the point of view of the user. We look at this site as a multi-use portal; it serves our members, our policyholders, many of our important business partners and our employees. One of the things we did when we upgraded to SP 2010 was to create separate content databases along these various groups. That we had to do this is a good thing, it means people are using the site. Of course, it also means that the URLs changed. Navigation from the top level site didn’t change, and the main URL didn’t change, but these people want to start at a place that makes sense to them; they don’t want to enter the front door and then walk down to “Men’s Wear.” Fortunately, we anticipated this problem, and we secured a domain name that will link them to the front page of the policyholder site – forever!

One of the things that we didn’t anticipate is how our site can be both important and trivial, and how that dichotomy influences what our users want. Our site is important, because it is a source of information that our policyholders need. Our site is trivial, because they have a thousand other things to keep track of. They rely on our content always being up to date; they want to know when our content changes but they don’t want dealing with that content or those changes to be a big drill. They want us to improve notification.

We thought that notification was easy – users can set up alerts and get notified of everything that changes, and they can have as many users as they like. Well, some of their users don’t remember to set up alerts, and they want some people to be notified without having them be credentialed users on the site. They want to have a contact list that can include users and non-users, and they want a “more descriptive email notification” to go out when content changes, not simply the SharePoint alert. I know that we can handle that request for one policyholder sub-site, and I think we can handle it for all of them with a roll-up list, but suffice it to say, we have some work ahead of us.

Another challenge that lies ahead of us is training. One of the changes we made during the upgrade process was to eliminate folders in the various document libraries. Face-to-face, I was able to show the benefit of having all the content in one place, and being able to sort and filter on the metadata. Apparently, “face-to-face” was the important part of that sentence. I was asked if I could provide remote video training. The answer is “yes I can,” but now that task is on my plate; I don’t think anyone from my awesome staff is going to volunteer to be the trainer. At least this will give us a chance to put Lync to the test.

I am famous for looking for the bright side to every situation (and there always is a bright side). When I look at this situation, I think about how lucky I am to be able to meet with these folks and get their honest feedback. Of course great food, open bars and a hike through a San Diego canyon helped set the stage for a comfortable exchange, but the important thing is that the dialog will help us turn a good site into an awesome site.