Make or buy: How to choose a KM system for your firm

Make or buy? This question has been around for much longer than the current incarnation of knowledge management has existed. Do I buy a house or construct a new one? Do I make dinner or go out to eat? Do I buy a piece of art or make my own? These are examples of make versus buy decisions that we may make periodically throughout our lives.

In a law firm context, an important question is whether to buy off-the-shelf KM software or build a new custom KM system in-house.

Should the firm buy a ready-made enterprise content management (ECM) package like Microsoft’s SharePoint, Open Text’s ECM Suite or EMC’s Documentum?

Should it use open-source Alfresco software and configure it for its purposes?

Should the firm hire external specialists or fund the internal IT department to create something that is custom-built for the firm?

The two main factors to consider in any decision to make or buy are cost and the availability of production resources (i.e. does the firm have the staff, skills, bandwidth, time and budget?)

Other considerations in make vs. buy decisions include the following.

Key considerations

Core vs. context

Consider the strategic importance of the application to be developed or purchased. Is the activity which the technology will support/enable core to the business?

For example, non-core activities for law firms include accounting, HR and payroll. Core activities include systems that support litigation and other legal services.

Coverage

Consider how close an off-the-shelf package is to what the firm needs.

A general rule of thumb is that 80 per cent of the firm’s requirements should be covered; however, it is not as easy as that. Whether or not the application goes above and beyond the firm’s requirements needs to be evaluated too, as well as the areas in which it falls short. If it is missing key requirements, it may not make sense to include it as an option.

Also consider how the system aligns with the firm’s business processes. If the technology cannot support business processes the way they are executed by the firm, the implementation will fail or be exceptionally costly to customise.

Direction

Consider the direction in which the software vendor is going with the application and how well it aligns with the firm’s direction.

This is more than just the stated requirements: it is future looking and includes considerations of how long the business and application will exist and be supported.

Total cost of ownership

The total cost of purchasing, implementing and maintaining an application includes not only the cost of acquisition, configuration and customisation, but also the ongoing support, maintenance and evolution of the application. It is quite common for the lifetime costs to eclipse the initial implementation costs.

An important component of total cost of ownership (TCO) is an estimate of the anticipated economic life of the application, i.e. how long will it be useful to the firm.

TCO is also a consideration in both purchased and built applications and must take into account the fixed costs associated with mastering the underlying structure and technology of either solution.

Scale

With scale, consideration is given as to whether the size and functionality of the application is appropriate to the size of the firm.

For example, is the application going to simplify operations or overly complicate them? Does the application have functionality that the firm needs and will use?

Timing

Consider the amount of time it will take the firm to get the application up and running.

The traditional view has been that implementing an off-the-shelf solution is faster than developing something customised for the firm.

However, the process of installing, configuring, customising and completing data migration for customised off-the-shelf solutions often involves tasks that are as complex as custom development.

Timing in custom development projects is problematic because of the challenges firms face in defining, documenting and controlling the required processes, as well as the issues that exist around finding knowledgeable and skilled developers who can create applications within the time allocated to them.

Industry standards

Consider whether the application is developed using industry standards. Using standards means that the supportability and operation of the application are more dependable, although problems are still possible.

Economic life

What is the economic life of the application? How long does the firm expect to use it and how long will it be useable and supportable? In theory, custom-developed applications have a longer life because the firm controls their maintenance and upkeep.

The problem with this, however, is that there is a tendency for firms not to properly maintain the application to ensure it is kept up to date with current trends and standards for applications. Applications are likely to stagnate and become outdated.

Volatility

Consider the frequency of new releases: there is a fine line between too often and not often enough.

If the application is custom developed, the firm will need to remember to budget the resources (time, financial and staff) for the ongoing costs of maintaining and improving the application.

With off-the-shelf applications, there is a cash outlay, but the time and staffing issues change to those focused on implementing the changes (which is the same for a custom-developed application), rather than developing the upgrade.

Business processes

Consider the ease with which the application can be aligned with the firm’s business processes. This is often easier with custom-developed applications, although it is possible with off-the-shelf applications too.

There is often some adjustment required in the firm’s processes in choosing an off-the-shelf system. However, adjusting the processes may be easier and cheaper than customising or developing an application.

The selection process

Historically, there has been a lack of choice in the marketplace for suitable, available technology. This resulted in firms hiring consultants or having a staff of software developers on hand so that they could internally develop the technology needed to meet their needs.

However, as technology has evolved, so too have off-the-shelf applications. Most of the time, it now makes more sense to purchase something off-the-shelf and customise and configure it for the needs of the firm, rather than to start from scratch and create something brand new.

Custom development does still happen and does make sense in certain circumstances where there is no off-the-shelf software available to customise and configure, or where the off-the-shelf software would cost too much to customise and configure.

However, as was discussed earlier, it is not just the initial costs to customise and configure the software which need to be considered, but also the cost of supporting and maintaining the application resulting from the custom development process and all those other criteria.

Support and maintenance of a custom-developed application can be time-consuming, expensive and difficult, as only the organisation’s staff who created it know how it was created. So, if they leave or retire, new staff have to be trained and educated in the application. Eventually, the application becomes so old that the technology used to create it is no longer available. Think of Y2K and all of those COBOL programmes.

COBOL is a computer language that is no longer in widespread use but, in the lead-up to Y2K, many organisations were facing issues with custom-developed applications that had been created 20 to 30 years before using COBOL. No one knew if provisions for Y2K had been coded into the programme or not, and what would happen at the stroke of midnight on 1 January 2000.

These applications were supporting key business processes, like finance, accounting and payroll, forcing organisations to find a way to update their applications or replace them before the Y2K ‘deadline’.

If an application had been purchased off the shelf, the company providing the software would have been responsible for maintaining and supporting it, not the organisations using it. In the case of Y2K, software vendors had to fix any date-related problems with their software.

The issues around Y2K happened because software developers were trying to save space. Storage space was previously much more expense than it is now, so reducing the amount of space programmes and data used saved significant amounts of money. They also expected that the applications written in the 1970s and 1980s (and before) would be replaced long before the turn of the millennium, so the date issue was not given any consideration.

The other, related issue was that organisations became dependent on the applications – which was not expected – and then they did not want to change to something new because of the time and expense (such as on requirements analysis, development, testing, training and data migration) related to migrating to a new software application.

These factors still exists within law firms. Once a knowledge management application is chosen, it will be used for much longer than the firm intends because it is so expensive and complicated to migrate to new technology.

Because of this extended life, it is critical to put adequate resources (time, money and people) into the selection process and to have an overall knowledge management strategy in place so that appropriate technology is purchased or developed.

The lesson in this is that, when making the decision to make or buy a KM application, it is important to ensure that all factors and requirements have been considered and that a thorough review has been made of the systems that are available in the marketplace.

There is a wide variety of applications available for purchase or through the open source community. They can be purchased for installation in the firm’s technology environment or purchased for use in a cloud computing environment.

Decision time

There are a lot of factors to consider in deciding whether to make or buy a KM system. The decision will very much depend upon the knowledge and skill level of the parties involved in the decision-making process.

Neither decision is one that should be taken lightly. Technology is a significant investment for law firms and the success of the overall implementation of the application will depend upon a clear internal understanding of the firm’s KM strategy and system requirements.

Stephanie Barnes is a knowledge management consultant

Endnote

For further information, see Aligning People, Process and Technology in Knowledge Management, Stephanie Barnes, Ark Group, May 2011