Is it really a requirement?

I never cease to be amazed by the antics of vendors trying to make problems simply go away without fixing them. The latest was a request from a vendor to remove an “issue report” because there was no actual written requirement to support it. You be the judge…

The problem was with software sold as a “robust financial accounting system” which turned out being neither robust nor even a real accounting system. When the first monthly close couldn’t tie out and we went to analyze what went wrong, we realized that there was no way in their system to link the debits and credits to the transactions that created them! You could see a list of transactions and even a list of debits and credits but the only way to see how they corresponded was to download everything into Excel and then manually move things around to where they should be and finally analyze what was left as the likely problem area. This was reported to the vendor to make sure that we weren’t missing something along with a request to find a way to show this relationship.

Their response was that “This is just the way the software is designed.” The vendor wanted the problem dropped since we didn’t actually specify in the RFP that the accounting system should be able to show what debits and credits were associated with a given transaction. Who in their right mind would have thought that you needed to specify such a thing when looking at a “robust financial accounting system”?

Later, we even found instances where the debit was in one month and the credit in another month. Then again, we didn’t write a specific requirement for that in the RFP either but at least in this case they agreed to fix it.

Buyer beware. If you are writing an RFP for a state insurance exchange, contact me!