The Killer App

b2ap3_thumbnail_killer_app_20130119-180614_1.jpgWe called it the Killer App, and, for the insurance industry, it was magic.

At least, it was supposed to be.

Forget waiting two weeks to get an explanation of benefits from the insurance company, two more to get a bill, then two hours on the phone to figure it out.  We were going to take care of the whole thing while you were at the doctors office.  To do that, we were going to adjudicate (that’s a fancy word for ‘process’) the claim in real time, so the customer could pay direct with an HSA Debit card — and know he was paying the right amount.   That meant taking the claim from the doctor, adjusting to the negotiated fee schedule, figuring who owed what, and reporting that back so the customer could pay.

After that, if the customer used cash and had a flex spending account, we would know they qualified to spend out of their FSA, and cut them a check back, from the account, automatically.


Like I said, it was the killer app.  I was working for the insurance company, and we hired a vendor to build us a system, to talk to the bank to calculate the balance on the claim.  My job was to write the software to pull from the claims database, compare to the amount in the Flex Spending Account, generate the flat file, and transmit it to the print vendor to make checks.

At least, that’s what I was supposed to do.

You see, the project was nine months late when I started.  The data tables I was supposed to pull from were not set up, nor did I have any written requirements.  All I had was conversations with a supervisor.

It was time for me to talk to people.

What is going on?

I started asking questions about the project.  Where were the business analysts?  Where were the requirements?  Where could I go to get a picture of the whole project?

Without an answer, I started pulling people aside and asking them in the hallway.

Keep in mind, I’m not a project manager here.  I’m not a line manager, or even a tester — I am ‘just’ a programmer, trying to find the information to do my job.

It was … an odd project.

Eventually, I realized that the project was something like eleven months behind – which is not so good for a project that was supposed to be done in fifteen months.  

The work I was doing was speculative.  I had to plan to pull from tables that did not yet exist (well, I had a data diagram, but the tables were not real, in the database), dump to tables I would design myself, then pull from those to create the file.

Meanwhile, another team was trying to get the data into the tables I would to pull from.  In order to do that, they first needed to get the system to process the claim, figure out who should pay what when, then insert rows into the tables I needed to pull from in order to generate checks.

Then I found out the front-end team had not run a single claim through the vendors system.

Not a claim file, not a days worth of claims – I am talking about one simple transaction, a patient that goes to a doctor and gets blood drawn.  Drop the file onto the system with one claim in it, and out comes … an error message, a failure, possibly a crash. 

When I went to ask why, the conversation became about blame.  The vendor claimed that we weren’t using the right version of the operating system, or of the database, or we had misconfigured something.  Meanwhile, our IT folks claimed they gave a list of our system architecture to the vendor before the project started, and the vendor signed off.  What was the problem?

Suddenly I began to understand why the project was eleven months late.

Advice Time

So I found the lead technical project manager in the hallway.  He asked me how things were going, and I told him: We were in trouble.  Did he know that we weren’t able to pay a single claim?  Forget automation magic and “the killer app”, we couldn’t get the new system to do anything with any claim at any time.

My advice was simple:  Get their tech guys and our tech guys in the same physical room.  Not on different coasts, not part time, not responding to tickets, get them all working on solving the same problem.  Lock the door, and tell them to figure it out.


An Actual Facebook war room; image by Robert Scoble, creative commons with attribution

The PM, who I call Biff, let out a slow sigh, and explained to me why that could never happen.  “If we do that”, Biff explained “then whatever goes wrong next, they will claim we told them to do in that little room with no documentation.  No, we can’t do it.  We need to communicate entirely in writing — we need a paper trail.”

Case Study Time

Today I’ve talked about my real experiences, on a real project.  Shortly, I’m going to post what I did, and what I learned, but if you don’t mind, I’m curious.  Before I say all that … play along with me.  You’ve just gone to the PM with your idea to fix the project, and this was the reply.  What is your assessment of the situation?  What should you do about it?  And what, if anything can we learn?

There’s a comment button.  What do you think?

Subscribe to our newsletter

Get the latest from the world of automations.