When should a law firm develop its own software?

Never. Law firms should never develop their own software. <end post>

Okay, fine, perhaps some explanation is in order. While the above conclusion may seem obvious to me and to many others, whenever I make this assertion on Twitter or from a podium, more than a few people will question my sanity or try to uncover my hidden bias. My bias isn't hidden at all. My view is developed from a lifetime of selling software, managing teams developing software, managing teams configuring and installing software, and managing teams buying and implementing software. Of course, the world isn't so black and white that one answer applies to every situation. But, by and large, law firms should practice law, not write software code. Here are 6 reasons why.

ivo

You need to stay focused. Smart business leaders outsource when (a) the all-in cost of buying is lower than the all-in cost of building; or (b) when in-sourcing will divert needed resources from strategic imperatives to non-core, non-strategic functions. Just as corporations hire law firms - because investing in a huge law department to handle all legal needs would be more costly and disruptive than hiring on-call experts -- law firms should outsource their non-core activities. So a law firm CIO is better off purchasing software that can be configured to the users' needs or, at worst, hiring a software vendor to write code specific to the users' needs.

Check your math. If your calculation suggests you should build vs. buy, you're likely doing the math wrong. The all-in cost, or total cost of ownership, isn't simply about software seat licenses, initial configuration, and ongoing maintenance fees compared to the sunk cost of Steve in the IT department who can write code. The all-in cost requires a broader look at the learning curve for common features/functions, R&D time for new features/functions, quality assurance and load testing, fixing bugs and releasing periodic patches, gathering ongoing user requirements, maintaining a product roadmap of features/functions having the widest impact to the user community, training users, providing front-end support such as password resets, providing second-level support for major bugs or conflicts, management reporting, and, oh yeah, coding. By the way, nowhere in your calculus or rationale should we find: "We have a software developer on staff and we need projects to keep him or her busy." Software purchases can be expensive. But it's short-sighted to view a vertical or enterprise application as solely a cost; it can be an investment too, with significant returns. Many organizations offset costs by demonstrable improvements in costly workflow, reallocating headcount doing things the old way, eliminating fees for outdated software, and even generating revenue.

You're not a special snowflake. Your users' requirements are not as unique as you think they are. Every single law firm partner believes the firm's work environment, internal processes, client interactions, and lawyers are unique. They're really not. What's worse, too often the most vocal advocates of a unique culture have literally never worked in another environment, let alone another law firm, so their perspective is meaningless -- despite what the org chart may reflect. A software provider with 10, 75, or 175 clients facing substantially the same business challenge may have deployed numerous iterations or configurations to address unique user requirements, but the core code is substantially the same and flexible enough to adapt to hundreds of other iterations. If you research existing solutions and don't find the feature or function you seek, it doesn't mean it's not out there. Sometimes a feature isn't in the base code but is commonly configured in the customer's deployment. Many times a feature or function is on a software vendor's radar but it won't be added to the next version until enough clients express a willingness to buy. Talk to trusted providers and you may find the path to meeting your requirements doesn't require starting from scratch.

Your requirements are incomplete. I can't count how many law firms I've encountered with code written to meet one specific partner's or one specific client's needs, as expressed through a vague description of desired outcomes, and ignoring all other viewpoints. Gathering business requirements and then translating them into technical specifications and then into code is a discipline, and even Agile and lean environments don't rely on coding to a single user's needs. Inevitably, if what you've coded is a good idea from which other internal users or clients would derive benefits, and it often is, the code you wrote for one specific instance -- especially if it contains hard-wired references to a specific client -- is very challenging to build upon. To scale it, you'll need to rewrite. In software development, it's better to think ahead and write modularly rather than frequently pay for one-time throwaway code. Also, capture input from all stakeholders. Countless times a partner establishes the requirements but the client, or the legal secretary, or the billing clerk, is a key influencer or user who had no voice in the development. It's no surprise why adoption rates are so low. Quality software developers capture input and seek sign-offs from all stakeholders before writing code.

Your discipline is suspect. I'm sure Steve in IT is a good code writer, even though his day job is network administrator, or help desk tech. Even if he's hired specifically as a coder, one resource isn't capable of gathering requirements, translating business requirements into tech specs, writing code, testing code, documenting code, conducting user testing, training users, and fixing bugs upon release. Having Steve attend a meeting with the partner and then begin to code from his meeting notes isn't enough. Few law firms invest in quality assurance and proper load testing, and even fewer invest in virtual environments to replicate their user community experience, including testing for conflicts with other enterprise applications. I've also run into law firms with the source code housed on one machine with no off-site backup protocol, and others where only one person has access to the source code. Just as you counsel your clients to hire the right law firm for the job, look for a disciplined and experienced software developer that isn't going to make rookie mistakes.

Reliance on a single point of failure is risky. We know that Steve doesn't have time to write up a summary of the business requirements let alone document his code. So what happens when Steve leaves and you need to fix or add something? Yes, of course you can find other coders pretty quickly, but their first task is to trace the existing code to figure out how things work. This takes time. And what if, as we inexplicably continue to see today, the current code base is ancient and the availability of coders fluent in that outdated language is limited? What if Steve leaves in a huff and deletes the source code, or changes the password?

I recently worked with a law firm that had developed a specialized application some years prior and dozens of clients had embedded this app into their workflow -- a perfect demonstration of the value of switching costs in a business relationship. Trouble is, the partners didn't fully appreciate the role of their two software developers and laid them off during a cost-cutting exercise. "We have other people in IT who can run with this," they said, ignoring the importance of subject matter expertise and specialization in a way that they'd never apply to the firm's lawyers. Predictably, the code faltered, the clients grew dissatisfied, and the clients untangled their workflows from a suspect system. (Side note: partner profits increased a healthy amount that year even as firm revenues grew modestly, but <surprise!> profits declined the following year.) Invest in the redundancies and peace of mind that come with purchasing software from trusted vendors.

The selection of a software package or provider is complex, as well it should be for enterprise or mission critical needs. Some vendors are better than others, and the size of the company or global breadth of the brand are often false indicators of competence. It's necessary to address to your satisfaction common questions and objections such as depth of domain expertise, development process, architecture and infrastructure, configurability of the software, compatibility with existing systems, responsiveness and service posture, and, not unimportantly, how likable is the team you're going to be doing business with for multiple years. And yes, the price tag on the software matters, but only insofar as it's one factor in your total cost of ownership calculation. (Side note: If you're a software vendor CEO and your team isn't incorporating TCO into its sales motion, call me. Your poorly-trained salespeople are missing opportunities to solve customer needs and close deals.) I know you're in a hurry. But if you rush to do a poor job instead of taking time to do it well, I don't think "fail fast" means what you think it means.

Keep in mind, the question isn't whether you can write good software code. Let's assume you can. It's safe to assume any competent coder can produce a good software application... once. But if your business case requires this code to be supported, upgraded, reconfigured, or replicated down the road, it's healthier to start with the premise that others are better suited to provide these services in a long-term business partnership. Avoid falling into the trap of assuming that "We can do this" or "It makes my job or my team's jobs more secure" is a good rationale. The best job security comes from finding the right people with the right skills and giving them the resources they need to be exceptional.

Timothy B. Corcoran is principal of Corcoran Consulting Group, with offices in New York, Charlottesville, and Sydney, and a global client base. He’s a Trustee and Fellow of the College of Law Practice Management, an American Lawyer Research Fellow, a Teaching Fellow at the Australia College of Law, and past president and a member of the Hall of Fame of the Legal Marketing Association. A former CEO, Tim guides law firm and law department leaders through the profitable disruption of outdated business models. Tim can be reached at Tim@BringInTim.com and +1.609.557.7311.