Getting Married and Software Implementation - similarities

Implementing new software systems, such as a small Payroll system, a Practice Management system and ERP systems, have a lot of commonalities as well as their own unique challenges and stages that span months or years.

However the the model of software implementation has been simple 2 step process in that it is: Purchase the software> Learn. On either side there is Vendor Demos, short listing of products, product selection and then after sale sign off, planning, discovery, scoping, requirements gathering, process changes, data conversion, testing, training, Go live strategy, etc.

The above seems pretty obvious. However my PCLaw selection and implementation model was opposite to the above conventional model. It was: Learn> Purchase the software. It is like a mini rollout before buying or actually committing to the system.

Whilst the former model is better suited for firms that have consultants support engaged in product selection, it is akin to finding a mate, getting married!

The latter, however is a slow but sure model, greatly reducing risk, ensuring a good fit where you greatly increase the chances of successful rollout. And it is akin to finding a mate, dating, getting married!

Which strategy would you choose to implement a new software system?

About Accurate Billing and Collection Reports

Billing and Collection information plays a vital part in law firms' remuneration structure. This information is constantly needed to make objective/subjective assessments of lawyers or partners productivity.

There are numerous reports in PCLaw to get this information. However for information to be consistent and accurate the system must be configured and data entry rules set to properly reflect the company’s policies on fee credits and collections.

There are a number of areas in PCLaw that need to be configured properly.

To begin under System Settings>Billing tab the option “Allocate fee changes to Resp Lawyer” determines if any Bill Up/Down of Fee amounts during billing should be allocated to the responsible lawyer or not. This is important and most firms leave it disabled if they wish the changes to be pro-rated amongst the working lawyers.

The next important area is under System Systems>Data Entry tab. Here you define how the collections are applied. Most firms leave it to Taxes, Disbursements and Fees in that order. It is important that this setting reflects the company’s policies and once set this setting is not changed. However this can be overridden on a case by case basis. For instance if the client is only paying the Disbursements and Taxes portion of the bill and not the fees, this can be allocated at data entry under Receive Payment>invoices tab>Payment details button.

The other area to look carefully at is at Matter levels Bill Settings. Here under Options “Auto Allocate Time/Fees to Working Lawyers” is checked by default and that is what most firms wish to allow PCLaw to automatically determine and allocate the fee credits to the lawyers working on the case at billing time in proportion to the value of their time spent. If it is the company policy for all fee credits to go the file holder then this option must be left unchecked (fee credits in such a case will go the Responsible Lawyer).

Within these parameters PCLaw still allows you to override who gets the fee credits at billing stage. If fee credit overrides is to be done, this can be accomplished at the “Prompt for changes to Billed Amount” stage during billing or at Matter Manger>Billing tab under “Split Lawyer Charges”. Firms must set clear rules embedded at Prebill levels for partners in charge of the matter to indicate desired fee credit allocations on Prebills.

Properly setting up the system and defining rules for partners, billing/accounts staff to follow for fee credits and collections is therefore vital to get accurate and consistent billings and collections reports.

Tiered Rate Structures

I had a situation for a law firm who took up a matter which would proceed in stages/phases and the rate matrix for each phase and lawyer was different.  The firm entered into a billing arrangement where it would bill fees based on the phase the matter fell under. So, lawyers working on the first phase had to record time at particular rates. If the matter proceeded to phase 2,3, etc the rates changed accordingly.

Below is a write-up I did on how to accomplish this.

General Overview of Rates in PCLaw

·         Rate Categories Assigned: Rates assigned for a matter are predefined in the system at firm level or matter level. Rates can also fall in categories and the individual rates for each timekeeper may vary for each category as defined in the system. For example: If a matter has the “A” rate assigned, lawyer ABC who has an A rate of 1000.00 will bill at 1000.00 per hour; lawyer DEF who has an A rate of 750.00 will bill at 750.00 per hour, and so on. It is also possible to change the rates of the timekeepers for any category effective from user defined dates.

·         Monetary Rate Assigned: A matter can also have a fixed monetary rate assigned as opposed to the A, B, C, etc rate category. For example: If a matter has a charge out rate of 1400.00, any timekeeper who records time on the matter will bill at a rate of 1400.00 regardless of his/her rate under each rate category.

·         Task Based Billing: A matter can also be billed by Tasks (known as task based billing). This is where time is categorised by task with each task carrying their unique rates.

Whether a rate assigned to a matter is category (A, B, C, etc) based, task based or a monetary value defined, further rate exceptions are possible with a number of permutations including the ability to bill by stage/phase.

Time Recording for Matters to be billed in Stages/Phases

Whilst an array and flexibility of billing rates & styles is possible, how to assign rates based on stages or phases of the matter needs some thoughtful planning. Some matters progress in stages and the lawyer may agree with the client a tiered rate structure based on the lawyer working and stage the scope of work falls under. It is possible to bill time based on the stage /phase and the timekeeper working on the matter.

Prerequisites for achieving stage based billing on a matter

·         Use specially created Task Code (e.g. “ST” for Specials Tasks) instead of ”BW” (Billable Work) at matter manager level under Main tab as the Default Task Code. Use this Task Code as default for all matters that will be billed in Stages/Phases.

·         Define the Stages/Phases at firm level – Useful to have as many stages as possible e.g. Phase 1, Phase 2, etc at Task Code level (Options>Lists>Task Codes).

·         Use Rate exception at matter manger level under Billing tab to set up as many timekeepers as possible.

·         Users have to use appropriate Task Codes (Phase 1, Phase 2, etc) when docketing time to have that matter billed at the correct rate based on the phase for which time is being recorded.

·         If user does not define the task code at time entry level, the matter’s default rate will be used.

·         When new timekeepers join in, apart from setting their default category A, B, etc rates, all matters with rate exception should be updated. To aid in doing this, the list of client matters report layout can be designed, and printed specifically for this purpose. The report can be filtered under Advance Search to show only matters with particular Task Code – “ST” in this case.

Client Account Surplus

Trust Bank Account transactions in PCLaw can only be associated to matters and not to any G/L accounts. This is probably due to the Trust Bank Account regulations in US/Canada for which PCLaw was primarily designed for. This means that any receipt or payment from Trust Account cannot be associated directly with any G/L account – the system will only accept matter allocations.

The above may present problems for new firms wishing to adopt the PCLaw system in jurisdictions in which banks have no Law Society rules they need to comply as far as Law Firm Trust Accounts go. Such firms may ponder with Trust accounting issues such as how to maintain minimum balances, how to account for non-matter related interest income and bank charges arising from Trust accounts.

The following is involved to get round this:

o   Opening of a Client Surplus Asset account (this can be a General Bank account or simply a current asset G/L account)

o   Opening of a client called “Client A/c Surplus”

o   Opening of “Client A/c Surplus” matters for each Trust Bank Account

Every time a non-matter entry is to be made from Trust you would use the Client Surplus matter for that Trust account. Then and opposite entry is done via the Client A/c Surplus Asset account.

Example:  Interest from Trust A/c needs to be accounted from Trust A/c 1 for 1,000.00. First one would do a Trust receipt against client surplus matter 0000-001 for 1.000.00. Then one would debit Client A/c  Surplus Asset A/c and credit Interest Income G/l account with 1,000.00. This is achieved via Firm Receipt (if the Client Surplus Asset account is opened as a General Bank account) or a journal entry (if the Client Surplus Account is opened as a G/L account).

At all times the balance in the Client A/c  Surplus Asset account must be equal and opposite to the total of Trust balances in all the Client A/c  Surplus matters. One would have to keep a tab on this manually.

I know in the past for different reasons PCLaw had a version for firms in Scotland to enable the association and tracking of the Client Surplus Asset and matter accounts. Firms in Scotland can have a substantial Client A/c Surplus and they can then overdraw the Trust Account for normal client matters provided the amounts overdrawn do not exceed the  balance in the Client A/c  Surplus. PCLaw had a feature to automatically track this. I am not sure if the Trust regulations for law firms in Scotland have changed or if Lexis still supports this version of PCLaw.

Should you move PCLaw from C-TREE to SQL?

In my prior blog post I compared effects of two offices of a firm running PCLaw C-TREE vs PCLaw SQL. The question is then should a firm implement / upgrade to the SQL or C-TREE version of PCLaw.

Whilst I am not a techy I have some experience working with a few CICs on PCLaw SQL set of issues and can give my view based on my own experience and requirements I have seen firms need.

CICs will give you conflicting answers and reasons for moving (or not moving) to SQL. One might then wonder: who is right and who is not? The short answer as one CIC put it is “there is no right or wrong answer..”. What works for one firm may not work for another.

Here is my take on it: As stated in my previous post, PCLaw just is not designed to work on SQL and can have devastating effects. There are however success stories of mid size firms using it well but my take is that if a firm feels it needs to move to SQL to get the benefits of SQL then it probably has reached a size it needs to take a holistic approach and assess its requirements. It may be that it has outgrown PCLaw. However if merely integrating with another software is the sole reason for upgrading to SQL version then it needs to explore other avenues.

My experience is that the C-TREE is better than SQL multiple times over because with C-TREE you have the following advantages (that are disadvantages of SQL):

·         Speed: C-TREE reports and routines are much faster than SQL.

·         Quick to implement and cost friendly: No techy /CIC needed and no additional cost outlay in terms of hardware/software.

·         Portability: PCLaw C-TREE database is easy to back up into a pla file and hence carry whenever and wherever one needs to and set-up. This has a number of benefits for a busy Accountant as stated below. SQL database on the other hand requires your Network Administrator or contracted / in-house IT staff to perform backups.

·         Creating a local set of books on a laptop or PC: For someone like me I carry a number of historic sets of books for different firms on my local drive. This allows access to historic or standalone set of books when needed. This historic data-sets has the following advantages: run and analyze historic reports via Excel, etc, trouble shoot problems, design new/edit existing reports/templates for later installation on a live system, test Security groups and restrictions before implementing on a live environment, test new functions & features using real firm data, review work performed by Accounts staff, etc.

·         Run VDI on a standalone: Sometimes running the Verify Data Integrity (VDI) routine on the live server may present problems. Quickly making a copy of the live dataset, locking it and installing on a standalone enables one to quickly run the VDI, perform a backup and restore the backup on to the live set.

I have always carried the data sets of firms that are on C-TREE whenever I have had to travel away. I ensure that the datasets I carry are most recent (a day old). One case I vividly recall was when I had to travel to a far away place where I could only get intermittent internet and email access. I was still able at my free time to generate all the Year End reports properly analyzed and email back to the auditors. All this without the need to remote in to the firm’s database (which would have been the case had the firm been on SQL). All I had to ensure was that I had a copy of the dataset with all the period and Year End adjustments complete. It was like carrying a brief case of accounts. The pla file was all I ever needed!.

I personally therefore would never touch a SQL database for the above reasons and also because of the inherent issues that the PCLaw SQL system is know for - data corruption, slowness etc. My mantra then; stick to the strengths of PCLaw and better the Devil you know.

A PCLaw SQL Horror Story

In the past I have seen two incidences when a firm decided to migrate the PCLaw database to SQL. Both related to the same firm, with the first being for one branch and the second for the other. Different databases for different offices; different reasons to migrate to SQL; and all for the same firm.

The reason for the first office was to enable better data mining, extraction of reports for business intelligence, ensure data integrity and minimize data corruption issues. The upgrade was a disaster, crippling the Accounts office and within two days the database was reverted back to C-TREE.  All happy going from then on.

The database at the second office was faced with a forced upgrade situation imposed upon by the consultants who were engaged in implementing a DMS (Interwoven Worksite). Without upgrade of PCLaw to SQL they were not going to touch anything. And that was after the firm had signed off the purchase (of Worksite)! In a nutshell there was a complete disregard of the Accounting system for the sake of PCLaw integration with Worksite. Despite the risks presented in a “crystal ball” fashion and despite earlier warnings, the firm upgraded to SQL.

Fast forward two years later: The Accounts office on the C-TREE database continued with greater speed and efficiency whilst the other office on SQL began getting issues that got from bad to worse. To put things into perspective the branch on C-TREE database was consistent in finalizing its year end accounts & audit by  February while the other office had the worst year as it took 9-10 months in finalizing its Audit/Accounts.

So, what went wrong? The cause is “Interwoven” – yes as the DMS name suggests all issues interweaved from slowness in report generation, data corruption, errors prone balances which the Accounts team relied, to finalizing periodic and Year-End accounts and audit. The domino effect had disastrous consequences.

A short horror story and simply because unlike more mature programs (Worksite in this case)  PCLaw was not designed to operate on SQL. So, should a firm upgrade to SQL or stick to C-TREE? That is probably a topic for next discussion.

PCLaw Security changes - when to update

In a prior post I mentioned by Security and how it works or is supposed to work and about user groups and rights.

The challenge I often have with the Security feature is when to constantly update. In a small firm the requirements might be very basic and user base constant. However for a larger or growing firm there are a number of issues to consider such as changes in timekeepers and support staff, changing roles, new features or functions required in PCLaw for staff to perform their tasks, etc.

So, once Security has been set and is working when should the Security features be revisited? The following scenarios according to me warrant updating Security rights:

·         Changes in Timekeepers – if new timekeepers are added, users who use the time recording function may need restricted access to the newly added timekeepers (under Advanced Security)  if they are not supposed to have access to new timekeepers’ rates, time reports, etc

·         Addition of new Bank Accounts – if support staff have restricted access to certain bank accounts and they should have access to the newly opened bank accounts, their Advanced security needs to be reset.

·         New features/functions – if the requirement of a firm changes such as new reports, new tasks, etc that users need access, security groups needs to be revisited.

·         New Upgrades/Updates – PCLaw releases new updates/upgrades and it is a time to test the Security again to ensure the latest features are available and also to ensure that the existing settings are working fine.

Other than the above, Security for matters can be done at Matter Manager level without accessing the actual Security feature. Firms must therefore have protocols to set security at matter level at time of file opening.

The Security feature therefore needs to be constantly refreshed after a firm defines how its going to use PCLaw.

About Reasons for Trust Overdraws and How to monitor progress of correction of Negative Trust Balances

Most firms operate Trust accounts and the operation of these Trust funds are governed by strict local bar and law society rules. However there are also firms that operate in jurisdictions with non existent or lax Trust Accounting rules and do not pay attention to trust account management. Worse things have happened to firms that also operate without due diligence and controls exercised by firm partners and management. The result is inadvertent or fraudulent Trust overdraws. Reasons for inadvertent Trust overdraws include:

 Accounting for trust transactions on incorrect matters: Writing trust cheques against wrong matters when there are sufficient funds at the time only comes to light towards the end of the matter .When time comes to dispose balance of the trust funds it is determined that the balance should be more that what is available. This anomaly can be caused by a) pure mis-postings by accounts staff or b) incorrect/distorted matter details availed to accounts staff by lawyers/legal staff. At the time of disbursing balance of trust funds, some lawyers, because of time constraints, will approve payments with instructions “to sort out later”. This is very true for instance, for real estate (property) transactions when there are completion dates that need to be adhered to and the firm is acting for the buyer and vendor and somewhere along the line disbursements for the buyer were incurred utilizing trust funds belonging to the vendor.

Multi Currency trust transactions: Firms who choose to handle foreign currency trust transactions do so by processing trust entries in their local currency whilst keeping a manual record for the value of foreign currency trust balance for each matter. This is a primitive method because one can track the foreign currency value as well as the reporting currency value of the trust balances in PCLaw (this is a topic for another day). Because of fluctuating exchange rates negative trust balances can occur although in reality the forex value of the trust funds is not negative.

Disbursing uncleared trust funds: Again some firms flaunt rules because ‘urgent’ payments need to be made and accounts staffs are instructed to process payments on matters before funds for that purpose have cleared the bank. When Trust receipts result in NSF trust balances go into negative.

Allowing Negative Trust Balances: Most firms restrict the occurrence of negative trust balances. This can be set under: Options>System Settings>Data Entry tab. However, this is sometimes left unchecked and subsequent trust overdraws warnings during data entry go unheeded.

PCLaw has a great tool to identify and manage the correction of negative trust balances. The Trust Listing report can be run for negative balances only. The report gives last trust entry date for every matter that has a negative trust balance. The Last Trust entry date signifies:

·         The last date of the Trust cheque that resulted in the matter going into Trust Overdraft

·         The last date of the Trust receipt on a matter that already had a Trust Overdraft but the receipt was not enough to move the matter out of Trust Overdraft

Once negative trust balances have been identified and are determined as genuine, the resultant Trust Listing report can be exported to Excel and sorted by Last Trust date. This Excel report will give the earliest and latest date and can act as a starting or ‘base’ report. Once the latest date is known on this base report, subsequent trust listing reports can be run for negative balances with advance search filter (that can be saved in the system) for dates greater than the latest date as per the original report. For example if the last Trust date per base report was 18/Jul/2012, under Advance filter of the Negative Trust Listing report, the date can be set as greater than 18/Jul/2012. By so doing you can identify if any subsequent dated trust entries have taken place on matters that have negative balances and is useful for tracking progress on correction and more importantly help prevent matters from aggravating further!

Of course on every report the total of negative Trust balances need to be checked and compared to prior reports to determine overall improvements/replenishment efforts!

PCLaw Security – Groups & Advanced User Rights

Security for user in PCLaw is a puzzle to be solved by trial and error method to achieve the optimum level of rights and someting that requires constant updating as firm requirement change, new software versions surface, etc. 

Security broadly is a function of a) Groups and b) Advanced User Rights. A user must be a member of one or more groups and each user can be further subjected to unique restrictions. A firm might want to give more than one feature or function to its group yet have restricted accesses for users.  These may turn out to be conflictive objectives to achieve thus making it difficult for PCLaw Administrators to strike the right balance between functionality and rights.

An example might be user rights for lawyers. The firm might want all lawyers to be able to record their own time, run their own time sheet reports without being able to enter time for other lawyers and see time reports for other lawyers, but with the ability to view the financial reports on matters such as Matter balances, A/R etc. By restricting lawyers from seeing other lawyers’ time, the information they will obtain will be distorted. This is true for a) Billing reports and b) Receivables reports if the Fee elements comprise of work done by other lawyers.

So, if an exception is created for individual users, the exception follows and is enforced upon the users in all areas of the program the users access – that’s how PCLaw works.