“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”
-Rich Cook
A surprising amount of core system reviews are under way at banks and credit unions right now. This is fueled by many factors, including growth at the institution, acquisitions, and new lines of business.
That’s no big news. But what is a surprise to us in the land of Gonz is that there is a very interesting and difficult issue being raised as part of the review – internally developed systems.
A while back my partner Carl Faulkner wrote an article about the fact that a number of banks we knew whose asset sizes ranged from $500 million to $10 billion were developing Internet banking applications, because their needs were fairly simple and the cost to develop internally was less (or was at least perceived to be less). Well, guess what? In our system selections and technology planning engagements, we have discovered a whole lot more than Internet banking systems under development out there in the bowels of IT. In fact, in numerous banks and credit unions we have seen these developed systems many times:
Man, we’re in a freakin’ development renaissance!
Now, the first reaction most readers would have to this is to ask what on Earth the IT group was or is thinking about. Unfortunately, it isn’t that easy. In fact, there were very good reasons the IT group undertook the efforts. One was that the core vendors were late to the game with a solution that worked and the clients got tired of waiting. Another was that what a focused internal development effort could produce for a line of business was better than what the core vendor could show – plain and simple (note to core vendors – sorry, but it’s true). A third was that a specialized sales, lending, or servicing group’s needs weren’t ever going to be met by any packaged system. In other words, there were very good reasons to develop at the time the decision was made.
But here’s the question of the day. Suppose the newer versions of vendors’ systems have eliminated most or all of the functionality gaps versus the developed systems. And their cost has come down. And they’re packaged with the core system. Do you keep developing?
This is a tough issue, because everybody has a valid point of view. IT groups are justifiably proud of their efforts and results. Lines of business are justifiably interested in alternatives. And management is justifiably wondering why to build if buying will produce the same benefits. And all three points of view need to be aired and an agreement reached about the rules of development.
Well, the peace-lovin’, God-fearin’ Gonzo team would never pose the conundrum and leave you high and dry. Here are some “rules of development” we would suggest that can help facilitate the conversation.
1. First and foremost, don’t get me wrong. There is absolutely a place for development, when it makes business sense. This is not a question of whether to develop, but a question of when and how.
2. Recognize that an internal development group is, in essence, a vendor and has to answer to the same standards as an external vendor. Formal needs assessments must be completed, deadlines met, users satisfied, service levels achieved – all of the things you demand of an external vendor apply equally.
This also means that the users of these systems have to act like buyers, not co-workers. We often talk to users of developed systems that privately express reservations but keep quiet when talking to IT because they don’t want to offend the people they eat lunch with once a week and sit next to at employee meetings. Programmers – sorry, but we hear this more than you think. Users – get over this reluctance. Nothing will hurt development more than diplomacy motivated by the desire to avoid hurt feelings.
3. If cost and functionality are mostly equal, buy rather than build. In other words, the internal effort has to earn continued funding/existence by producing results that are measurably better or cheaper than third party alternatives (note to IT managers – sorry, but this is a market truth). This is because developing with a small internal team is riskier than buying. Don’t agree? Ask your external auditors and regulators
4. Users, and nobody else, decide which systems have better functionality. And they are exposed to multiple third party alternatives on a regular basis. This seems obvious, but we have talked to IT groups who tell us that they have looked at alternatives for the users and found nothing better out there. Uh huh.
5. The more focused and isolated a business need is, the more argument there is to build. The broader and more complex a need is, the more argument there is to buy. The most successful development efforts target the unique needs of a unique department. Some examples we have seen:
These are all examples of development efforts that met a legitimate need in a way that an outside solution could not and, as a result, created real credibility in the eyes of management.
6. Accept that developed systems may have a specific useful lifetime. It’s OK if something developed for a specific purpose becomes outdated or gets replaced. For example, we recently were in a bank that had developed some sales tracking/reporting capabilities three years ago because the vendor’s branch solution didn’t have anything for them. The next release of the vendor’s branch product does. Both the users and IT agreed that while the developed system had performed very well, it made sense to migrate to what the core vendor had integrated into its solution. The net result for IT was that their credibility jumped within the bank.
7. Be honest about development costs. We often find that in looking back at the development of a system, few IT groups can show what the true cost was – developer time, third party consultants, line of business hours for definition, software, etc. And when cost estimates are created for a new development project, there is often an underestimation of internal programmer time that will be needed in future years. “It will just take Carl three months and we’ll be done” usually proves to be too optimistic. Internal groups need to submit cost estimates that address all the same areas as a vendor proposal.
8. Watch out for scope creep in developed systems. There is a natural tendency to keep adding to what a system can do, but the benefits may not be there. We have seen several examples of this – a simple credit scoring interface grows into a complete loan origination system. A data mart that was focused on one group becomes an enterprise data warehouse system. A branch fulfillment system morphs into a CRM system. Unfortunately, the end result can be a system that does several things poorly instead of one thing really well. Or, it can result in an effort that is terminally 85% complete. Both results are unacceptable to the buyers.
Developed systems can add real benefits to a bank if they’re focused and done well. So, let’s do them well.
Well?
-tr