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.