Solving the Right Problem

Some recent project work reminded me of an old theory of mine about software development: sometimes the hardest thing in designing a system is to understand what problem you are really trying to solve. In particular, the difference between a good system and a bad system is often the way the problem to be solved was framed and articulated to the team.

It's all too easy to race directly to the immediate issue or goal that a project is trying to accomplish; it's much harder to take a step back and get a more abstracted view of the overall problem.

In this case, we were designing a system to manage the process of filing insurance product information with state Exchanges. As we talked through the objectives, everyone was very focused on what we had to do in a few months: file a bunch of specific templates full of data with three different state Exchanges. We had a list of the 12 documents that were going to be required by one of the Exchanges, and while we hadn't received any definite information yet from the other two Exchanges we assumed their filings would be very similar.

The high-level business requirements were simple: rather than having the people doing the filings store their documents on their local PC file systems and email them around to each other, create a simple document management and workflow solution (using COTS packages, fortunately, not coding stuff from scratch.) It needed to allow users to upload the filings documents to a secure, version-controlled, and auditable location, track the state of the documents from initial draft to final submission, and route them to other users for steps in the process like data validation and approval.

When the first screen prototypes came back from the team, they showed a user interface with one tab for each of the documents to be submitted--prescription drug template, service area template, etc. On each tab were specific controls  to let you upload the associated document and drop downs to change its state. You could create additional "certification filings", but each one would have the same hardwired set of tabs.

"Let's back up a minute," I said. The design would have worked fine for the first filing for that one particular Exchange, but it wouldn't work for the other Exchanges unless they had the exact same documents required to be submitted. And, if next year one of the Exchanges decided they needed to remove one type of document and instead have insurance companies submit, say, a new report on drug utilization statistics, well, we'd have to spin up a new project and have developers go in and revise the system.

What we really needed to create was not a system to manage product filings for three specific Exchanges but rather a submission management system that allows users to manage a definable and changing set of documents to any sort of external agency. We talked through it and got everyone in agreement and off the team went.

The end design was for a very flexible system that allow end users to define "submission packages" and create within them any number of documents. An Exchange could change their submission requirements all they want  in the future and the same system can be used to manage the filings without needing a single modification, and it could be used to manage any number of other regulatory filings, too.

In the end, it all came down to the way the problem was framed. Once we stopped talking about the immediate need--filing those 12 documents with this particular state Exchange--and instead discussed the solution in terms of the bigger picture need--a system to manage a wide range of document filings with regulators--we got the proper results.

If you have good design and development teams, they can generally figure out how to solve any problem you throw there way. You just have to make sure you turn their talents loose on the right problem.