In Search of Value

Value Hierarchy

Apologies to Maslow

One of the goals that I have maintained throughout my career has been to add value to a process. Long before SharePoint, in fact long before (OK, little before) Microsoft, value was a key requirement in the systems I was building and designing. As a young systems analyst, I remember receiving strange looks from my “customers” when I would ask: “how would that report help you?” I used reports as an example because people always seemed to want more reports than they needed. Once, when I moved a system from one platform to another, I didn’t bother recreating 90% of the reports. I promised to build each one as the need became critical. I only ever recreated about another 5% of the missing reports.

I would get equally strange looks when I would ask my IT colleagues: “how would that add value” or, somewhat more surprising: “how can we build this and be sure we are adding value?

Don’t let me paint too rosy a picture. I’ve built my share of systems that missed the sweet-spot of the target and I’ve left more than a few valuable features laying on the cutting room floor. Systems development has always been affected by drama and budget, in addition to logic.

As I am managing what will likely be my last long-term development effort, I am focusing more than ever on value. I have 3-5 years left to make a start on a new generation of systems, and if I am successful, those systems will be built on a foundation of “adding value to a process.”

I haven’t had much to share on this blog in recent months, but some projects are reaching a point where I can talk about them in generic terms. In most cases, I can’t talk about the work, because I’m not doing it. I can’t talk about the players, because some would rather not be a part of my blog entry. I can’t always talk about the details of the project because legal/accounting/human resources – ‘nuff said. But I can talk about goals and objectives and the way a focus on value has led us to some interesting decisions. Decisions I might not have made back when I started this blog and was bent on using SharePoint whenever possible.

By way of introduction to what I hope is a small series of blog posts (maybe enough to satisfy @Sympmarc’s Saturday addiction) let me share a couple of thoughts on how we got to this point.

Success moves you higher – I am old enough to have participated in systems development projects where the primary goal was to automate transaction processing and save money by eliminating jobs. Oh, we told ourselves that we were improving accuracy and letting people focus on higher-order tasks, but we were also letting them find those tasks at a different company. By the time SharePoint became available, we were way beyond that kind of development and we were looking for ways to use the information we had been gathering. SharePoint offered us a way to move up the hierarchy shown at the top, just a bit.

Failure also moves you higher – The reason I put the “Process Improvement” layer in quotes and in red and with the snarky bit at the end is because it wasn’t always the result. Often, process improvement was a collective bridge too far. Business leaders wanted magical solutions and technical managers and staff couldn’t wait to buy/build/use new toys in pursuit of that magic.

Automating a Business Process

There are times when you can run the table and automate the whole thing. There are also times when that would be a bad idea.

The diagram above illustrates where we sometimes went wrong and how we are correcting those mistakes. Consider the five boxes across the top. Occasionally we have felt that we could automate all of them. In fact, we could. Unfortunately, automated analysis and decisions, by default become arbitrary. A report is on-time, because it is not yet late, or a report is late the moment the time allotted has passed. People on the other hand, understand that a report nearing its due date may be in trouble and people understand that sometimes life gets in the way of an arbitrary due date.

Note: I have been doing this stuff since the ‘70s and yes, I know that systems can be made to be more holistic in nature. However, the effort in building those systems, as well as the effort to maintain those systems is very often too high. Humans are much better at making holistic decisions than machines.

We have recently taken technology out of some steps of a business process that we had previously automated, in order to improve the process. Instead of automating all of the steps, we are focusing on “what information would help humans complete this step easier/faster/with better results?” I put this in the win column because we have the information we need (because we built good solutions in steps one and two). Now, by utilizing SharePoint’s native features, we can provide good information for people to consider in steps three and four. And yes, since nobody wants to do recordkeeping, we will automate that last step.

That’s it for today. I have some stories in mind that build off of this foundation, but those can wait for another day. Maybe not next Saturday, but let’s keep this a Saturday kind of read.

Mea Culpa

imageA couple of weeks ago I wrote about how we are using SharePoint to support a Holiday Door Decorating Contest in our office. Well, the doors are decorated and the votes are in. The winning door is shown at the right, and some lucky charity is going to receive a nice donation. Unfortunately, the SharePoint part wasn’t as simple as I had hoped. Although some people think others said this first, I’m going with the fact that Albert Einstein said:

“Everything Should Be Made as Simple as Possible, But Not Simpler”

In a developer’s twist on Einstein, I would say that “perhaps I was hoping for my task to be too simple.”

I made a newbie’s mistake. I made a mistake that I shouldn’t have made. I made a mistake that many people in the SharePoint community complain about people making. I took something out of a blog, pasted it into SharePoint without taking the time to fully understand it. To make matters worse, the person who wrote the blog had explained everything very well. I glossed over that section of his post because; well because A) I was in a hurry. B) I was thinking “yeah, yeah, I get this” and C) It was a door decorating contest! I mean it’s not like the site was calculating premium for a nuclear reactor (we actually do that, so…).

As I said in my earlier post, we don’t work with images very often. In fact, all of the other times that we have worked with images, we’ve just plopped a default picture library onto a site and dumped a bunch of JPG’s into them. Here’s a partial list of things I didn’t know about picture libraries:

The default columns (file size, picture, size, selection, etc.) activate themselves when you edit a view. So, unless you turn them each time you edit a view, they show up again and your neat and tidy view looks stupid.

The thumbnail is available as an optional column that you can show in your views (I mentioned in my earlier post that I didn’t know where this could be found and I used a solution to build the link to the small image).

The thumbnail image is linked to the view properties. I wanted to have a link from the thumbnail to a full sized image, preferably one that opens in a new window, so I ended up using the solution I mentioned in my previous post anyway.

The default view of a picture library doesn’t seem to preserve all the view settings. A picture library view can show details or thumbnails or be a filmstrip but the URL is the same. Some people saw the details view (that I included in my instructions) and some saw the thumbnail view that made no sense at all since it didn’t have the link to cast the vote.


As for that link, the one I built to start the workflow that “casts” the vote (a.k.a. the idea I copied from the blog) I only didn’t understand one thing, but it was a comically critical thing. The GUID of that workflow changes each time the workflow is published because the workflow is versioned. That makes sense, but because I didn’t know that, I was reacting to the error I got when clicking on the link as though it was an error in my workflow. You can imagine the frustration that ensued as I kept trying to correct a workflow that really had nothing wrong with it. As I write this, I’m trying to figure out which of my friends are just laughing and which are also thinking “it serves you right” while they laugh.

Let’s count the mistakes I made:

  1. I skimmed over a blog entry, modified a solution and stuffed it into my library.
  2. I didn’t fully investigate the attributes and behavior of the SharePoint feature (the picture library) that I was using.
  3. I published a solution without having a user other than me test it. If I had had one other person test this, I would have discovered the issue with the view because the person I pick on for testing saw the thumbnail view, not the details view.
  4. I decided that the nature of the business process I was working on wasn’t worthy of my full attention and / or best effort.

I am most disappointed in myself over number 4. Everything we do in SharePoint deserves our best effort. Every project that doesn’t represent our best effort contributes to the various negative perceptions people have about SharePoint. A fun project like this is a great way to show what SharePoint can do and I almost squandered that opportunity – ho ho ho!

Note: I didn’t compound my newbie mistake by complaining to the author of the blog. I went back and studied what he wrote, pulled my head out of my … the darkness and made the library work like it should have worked at the start.