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.

Will We Ever Get This Right

Almost every IT shop has an inventory of projects. imageSome 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.