Andrew Levison Head of UK and Europe ConsultingServices at Baker Robbins (in alliance with Grant Thornton) and co-author of theIT Interfirm Comparison can be contacted on 07860 584812 or alevison@brco.com
In the last 15 years the market for legal services haschanged considerably. Fixed fees and conditional fee arrangements are in use,and tendering processes are now common. Clients are both more cost conscious andmore quality conscious. Law firms need to be aware of the variables thatcontribute to their cost and charging structure to avoid taking on work at aloss. The information they require tends to be stored on their PracticeManagement System (PMS) but, in older systems, extracting it for reporting canbe problematic and may require expensive reprogramming.
Modern systems are more flexible andusually allow user-defined fields that let firms ‘cut’ the informationstored in multiple ways to enable reporting to the firm’s management to bepresented in different ways, often pictorial. They usually include a reportwriter that can be used in-house to retrieve required information and anExecutive Information System (EIS) to allow management fast access toperformance statistics.
The implementation stage of most ITprojects tends to be the most difficult and challenging, and the implementationof a modern PMS is no different. The degree of effort required to implement newsystems or changes to systems quickly and successfully is often underestimated.Insufficient time is allocated to training and practice in the use of the newsystems and procedures.
Successful implementation comes down to the quality of planning,both in the early stages and ongoing throughout a PMS implementation, withfeedback through a project committee or board. It is this body’s role tomonitor the project and provide assurance to the firm that the project will bedelivered on time and to the correct specification. If project slippage occurs,extra resources to get it back on track, or a revised plan, are required.
The steps to be taken in implementing a PMS are:
• building the team
• integration
• hardware procurement
• business processes and set-up
• conversion
• development & testing
• go-live & catch-up
• training.
Building the Team
It is important to havehigh-level sponsorship for the project. It is equally important that the sponsorshould be committed to the project, be enthusiastic about progressing it andhave a keen grasp of the business issues involved. The team itself will probablyconsist of a mixture of IT personnel and functional specialists. Depending onthe time constraints, it may be necessary to employ contractors if the requiredskills are not available in-house. It is useful to have a mixture of existingand new staff to work on the project; existing staff will know the currentprocesses and the firm’s culture, new staff, are more likely to challengeworkflow assumptions.
A channel of communication (such as a monthly newsletter) should beset-up so that the firm is aware of progress on the project.
Allocating sufficient resources is vital to the project’ssuccess. In Grant Thornton’s Legal IT Interfirm Comparison, suppliersindicated that the three highest priority actions for a firm to improveimplementation are to allocate sufficient resources, appoint a full-time projectmanager and give sufficient high-level support/financial authority to theproject team.
Integration
Many firms have disbursementtracking, document management and case management in place, some or all of whichmay have to be integrated with the PMS. Integration can be one of the mostcomplex areas in setting up a new system. Taking a number of different softwareapplications, running on different hardware, supported by different suppliers,and using different protocols and getting them to communicate with each other ina sensible and timely manner can take a lot of resources. Technical constraintscan dictate how the systems integrate and can affect the business processes, andhow the system is set up. It is advisable to look at integration early in theproject, before even committing to the PMS contract.
Hardware Procurement
It is likely that new serverswill have to be purchased. The firm’s existing PCs may not be capable ofrunning the new PMS together with other existing applications. New printers maybe required; current cheque and label printers may not be compatible with thenew system.
There will be a lead-time before equipment is delivered to thefirm’s premises – this may have an impact on the project plan, especially ifservers cannot be obtained quickly. If the firm’s current PCs are beingreplaced, there needs to be consideration given as to when the PCs are rolledout to staff and who carries out the work. It may be advisable to carry this outin advance of go-live – otherwise IT resources may not be sufficient.
Business Processes & Set-up
During the tendering andselection process the firm will have started to clarify what functionality itwants from its PMS. The firm now needs to look at each process affected by thenew system and document the existing workflow and the new workflow includingexisting and new reporting. This should include the controls and checks in theexisting processes and how they will be recreated within the new system.
Reporting requirements need to be addressed early. The standardreports that come with the new PMS may not be suitable, in which case newreports will have to be written. It may be possible to get them written by thesupplier; alternatively, if reporting is seen as a development area, it may beworth training in-house staff in report writing.
If billing is to be carried out online it may be necessary tocreate and set up bill templates on the system to support specific clientbilling requirements. Cheque templates will need to be set up to support onlinecheque printing. If the firm intends to change the format of its cheques, itsbank should be contacted early so that the process of selection, proof approvaland printing can be completed prior to go-live.
Once the new business processes are completed they should beagreed and signed off by the supervisors of the functional areas to which theyrelate. This will provide some reassurance that the processes are complete.
Management reporting should be examined at this stage. ThePMS should support the firm’s business plan and be capable of returningfirm-specific performance indicators to show whether it is being achieved ornot.
Development and Testing
The business process review willgenerate a list of operational requirements for the new PMS. Testing ensuresthat the system is capable of supporting those requirements. At a minimum thesystem should be tested against the specified operational requirements. Wherethere is functionality that may be used in future but which is not currently arequirement, this also can be tested, both to ensure that the system responds asexpected and to check whether there are any requirements in setting up thesystem.
Testing should be thorough and methodical. Test plans shouldbe drawn up, derived from the business processes, and the data selected fortesting should be representative of all data in the system.
Where time allows, a ‘day in the life’ test can be run.Effectively all items posted on the legacy system on a specific day are postedon to the test PMS system. Checks are run between the legacy and the new systemto ensure that balances and transactions agree. While this test providesreassurance that the PMS can support the day-to-day business, it does requiresubstantial time to carry out; the test system must be set up to hold allprerequisite data for the ‘day in the life’ test. For example, in order toissue bills during the test, all time and disbursements required for billingmust either already be on the system, or must be input during the test. Furthertime needs to be spent in reconciling the two systems. The specific day chosenshould contain as wide a cross section of input as possible.
Where the results of testing indicate that functionality is lackingthen the business processes need to be changed to ‘work around’ thefunctionality, or the supplier needs to be approached to improve functionality.
Conversion
Conversion relates to thetransfer of data between the legacy system and the new system.
The objective of data conversion is to ensure that the datatransferred from the legacy system to the new system is complete, accurate andconsistent and can be used to support ongoing data processing. A number of keydecisions must be made before starting data conversion:
• What data is to be convertedA series of ‘rules’ need to be drawn up for each data type. The rules must be consistent with each other. It is particularly important to make sure all standing data required to support transactions is converted. For example, a rule that says convert data for:
All matters open at the date of conversion
Client account transactions for the last six years
leaves unspecified how the matter data for closed matters with client account transactions within the last six years
will be treated.
• How the data is to be convertedData mapping requires identifying the source data field from the legacy system and the related target field in the new system. Data may have to be converted from a number of legacy systems such as marketing systems.
• Duplication and consistencyData will need careful examination to ensure that there is no duplication (for example duplicate clients), and that data is internally consistent (for example, no closed matters with work in progress balances).
• Cleaning systemsWhere there are data errors on the legacy system, a decision will need to be made as to how to ‘clean’ the data. Where there are large areas of clean up and a general rule can be applied, the clean up can take place through conversion routines. Where the clean up is ad-hoc, such as duplicate client names, it may be necessary to have a rolling program that continues up to and past go-live.
• When the data is to be convertedThe cut-off dates for test conversions and live conversion need to be scheduled well in advance so that resources can be allocated as required. The test conversion cut-off dates and times should enable easy checking of balances against the legacy system, for example at month-end.
• Avoiding orphansWhere data is converted from a number of legacy systems, the timing and sequence of the conversion will have to be managed so that there is no ‘orphan’ data in the new system.
Training
Training can make the differencebetween a new system being perceived as a success or failure. In the GrantThornton Legal IT Interfirm Comparison there was a strong correlation betweenhigh levels of training and satisfaction with new systems.
The timing of training is extremely important. The best timing isjust before go-live to enable staff to become familiar with the new system. Thedifficulty is that this is likely to create a bottleneck where trainingresources become stretched. One solution is to identify the power users andtrain them extensively around go-live, at the same time setting up overviewsessions for those less likely to be using the system, with further workshopsarranged when the immediate stresses of go-live are over.
Go-live and Catch Up
When the data is taken from thelegacy system, there is a delay while the conversion processes are run to importit into the new system. Once the data has been transferred, testing should becarried out to ensure that data conversion has been carried out correctly. Thiswill involve testing specific transactions between the legacy and new system,and also reconciling control lists. After the firm is satisfied that the dataconverted is complete, the system can be released to a limited number of usersto start catch-up.
Depending on how much data is being transferred and the complexityof the legacy and new system, the delay between taking the data cut andconversion completion can be up to two weeks. During this time there will besome data being input into the legacy system – at the minimum it is essentialto input client fund information to ensure SAR compliance. Once the system hasbeen released, the first step is to input into the new system all thetransactions that have already been input into the legacy system. These must beinput in a planned manner so that any differences between the legacy system andnew system can be identified and if necessary corrected, on the new system.
When catch-up has been completed,the firm can either switch off the legacy system and continue solely with thenew PMS, or run in parallel. While parallel running gives reassurance that thenew system is working correctly, it will almost certainly create resourceissues, as all transactions have to be input twice.
The period of catch-up will invariably create resource problems forthe finance function as two systems are being run simultaneously, with periodicreconciliation being made between them. It is advisable to put a moratorium onholidays for at least catch-up and the first weeks of go-live once the dateshave been identified.
After go-live firms generally go through a period of system supportwhen staff are adjusting to the demands of the new system but implementationshould really be considered only the first stage in putting in a new system.Once the system is up and running the firm should plan the next stages indeveloping the system so that functionality can be maintained and built upon.
