An expensive lesson for the chairman

“It's been a year and $100,000. Now you're telling me we have to start over?” exclaims Keith Mayfield, chairman of an AmLaw 100 firm, to the director of the firm's IT Department and the head of the firm's Corporate Division, which is by far its largest lawyer group.

What they're discussing

Keith is referring to a high-profile system being built to automate the semi-annual process of Corporate Division partners providing performance reviews of associates. The current system involves a very long weekend meeting of all 50 of the Division's partners, during which each partner shares with the entire group his or her views of each associate with whom the partner worked during the previous 6 months (over 150 associates). Various partners are assigned to take notes as the basis for performance reviews to the associates. After views are given, the partners engage in a group discussion of those associates who are within two years of a partnership decision.

The new system is intended to allow the partners to type their views on-line in advance of the meeting, using numerical ratings on structured questions as well as free-form comments. A summary, organized by associate, is then compiled automatically and distributed to the partners in a binder for review in advance of the meeting. The goal is to shorten the weekend meeting dramatically by limiting the review collection aspect of the meeting. Under the new system, that discussion need only resolve conflicts among the comments previously submitted. That allows partners to focus their discussion on partnership prospects of associates.

In the end, the system was late and over budget. The worst part was that in pilot testing the partners hated using it and said they would probably ignore it if it were introduced.

What went wrong

“The lawyers kept changing the requirements on us,” explains the IT director.

“The system couldn't adapt as we evolved how it should work,” replies the Corporate Division head.

During a painful postmortem, the following facts come to light:

• Business requirements kept changing. The lawyers running the project were learning what they needed as the system was being built:
  • At first, the lawyers wanted only a simple on-line form that each partner would pull up and enter into the system.
  • Then they realized some partners' secretaries would also need access, but flip-flopped over whether access should be given to all or only some partners' secretaries. They ultimately decided (after the some-secretaries version was built) to allow any partner to create access for his or her secretary for a specific review period through an on-line button accessible only by the partner whose secretary was to receive access.
  • Then the lawyers realized the system should provide partners with lists of the matters on which they had worked with the associates during the specific reporting period, so that the partners' comments would be focused on the correct associates and matters and would be limited to interactions that occurred during the reporting period.
  • Next they decided the partner user experience required that the above two aspects be integrated, so that each partner would be presented with a customized on-line form for each associate who had worked more than a threshold number of hours on a matter with that partner, together with a list of those matters.
  • Finally, the lawyers realized that workflow needed to be incorporated into the system, so that a completed or partially completed on-line review form could be routed to another partner for further information or comments and either returned to the first partner or submitted directly by that other partner.
• IT Dept. just went along. The IT Dept. decided to develop the software internally but, because it was a high-profile partner-level project, hired additional outside software programmers so the work could be completed in the most timely fashion. As the lawyers changed their minds, the IT Dept. did not push for a high-level meeting to address the need to finalize the business requirements. Instead they dutifully worked on the revisions, hiring even more programmers as the project fell further behind. The IT Dept. did not tell the partners that outside programmers had been hired and did not raise cost and programmer resource allocation issues with the partners.
• Partners were not committed. Due to the press of client work, the partners were slow in testing each successive version of the system, creating further delays.
• The system imposed a big culture change on partners. Introducing the system required too big a culture change for the partners. They were used to providing comments about associates in a free-form discussion setting. The system asked them instead (a) to provide comments according to specific talent development areas (legal writing, organization, leadership, initiative, client relations, etc.), which required partners to think about their comments in a new way that took much longer, and (b) to write down their free-form comments, which had a somewhat chilling effect on candor.

How it should have been done

Three important conclusions can be drawn from the postmortem:

1. A business process should be worked out manually before it is automated.
   

   In the case of Keith's firm, the new process of providing written comments in advance should have been piloted using paper forms and a manual compilation effort to produce summary binders. Sure, that entails extra administrative effort and takes the partners a bit more time, but it makes all the difference when it comes time to automate.

   The manual process will evolve and ultimately become fixed. Automating a fixed manual process is far more efficient than repeatedly revising the software to follow changes in the process. For example, it would quickly become apparent during the manual process that the partners should also receive a list of matters showing associates with whom they've worked during the reporting period.

2. Culture change should not be introduced as part of a new automation process.

   Lawyers dislike change. They especially resist culture change. That should be tackled as part of the manual process prior to automation. The lawyers will accept the automated version much more readily if it closely parallels a process they already accept.

3. The IT Dept. should be empowered to impose basic project management principles on the automation project.

   Lawyers are not project managers. (Clients are pushing them to become better in that area, but that is a topic for another discussion.) When working with the IT Dept. on a project, lawyers often believe that an oral description at one meeting is all they need to do and that the IT Dept. can then just build it. Instead, there needs to be more discipline in the project:

   1. The business requirements need to be documented in detail.
   2. Screen shots need to be created and agreed.
   3. A timeline needs to be established. Among other things, this enables the IT Dept. to decide whether to hire resources or use their own staff. The timeline should take into account some unavailability of lawyers due to client work; but lawyers must also make the automation project a priority.
   4. Changes in requirements or other scope changes need to be formally reviewed and approved after analyzing their effect on the timeline and the budget.
   5. Lawyers need to remain involved for testing and feedback.

The issues surrounding collaboration of lawyers and the IT Dept. are further discussed in my prior post “Lawyers and technologists – aliens or allies?”

What the firm does next

Having learned an expensive lesson and spoken to a consultant, Keith sends the head of the Corporate Division back to develop paper questionnaires for the partners to use at the next semi-annual meeting. That process will introduce the partners to the culture change and, if it's successful, immediately improve the efficiency of the meeting. Paper lists of matters on which each associate worked during the review period would be distributed to the partners with the questionnaires. Administrative assistance will be arranged to compile the partner summary binders manually. Depending on how well the manual system works, the next step could be automation, or a revised version of the manual process (such as changes to the questions) at the subsequent semi-annual meeting.

Keith also asks the Corporate Division head to work with an IT Dept. project manager after the meeting to prepare a write-up describing the manual process that was followed. This will be used as the starting point for the actual business requirements of the automated system, which will further developed through interviews the IT Dept. will have with the Corporate Division head and a handful of other partners.

Finally, Keith instructs the director of the IT Dept. that he is responsible for imposing discipline on the process, including monitoring scope changes, timeline and budget, and raising issues as appropriate with the head of the Corporate Division and, if necessary, with Keith himself.

All kinds of projects can benefit from this approach

There are any number of law firm situations that can benefit from the principles Keith's firm learned the hard way. Lawyers regularly come up with new initiatives that are, in the lawyers' minds, closely coupled with automation.

Collecting matter experience data

For example, a practice group may decide to collect experience data about its matters, such as type of matter, industry, special features of the matter, amount involved, completion date, etc. Part of the proposal may be to create an on-line input form and flexible database with sophisticated reporting capabilities.

Applying the principles described above, the project should start with a Word or Excel questionnaire that is competed and e-mailed to a central administrator, then retyped and stored in an Excel spreadsheet. After the questions are finalized through use of the system, after the lawyers accept the culture change of completing the questionnaire at the end of matters and after other kinks in the process are resolved, it would be time to consider building a more robust automated version. In the mean time, the data can still be accessed through the Excel spreadsheet, which has sorting and filtering capabilities that should be adequate for many purposes.

Building legal project management tools

Another example is the development of a legal project management tool, such as one that assists in creating budgets or in tracking actual performance against budget. Following the principles described above, the tool should first be developed based on manual processes that rely only on common software with which the lawyers are already comfortable and that can be used out of the box with no software development, such as Excel and Outlook. After the lawyers have adapted to the significant culture change associated with using the tool, and after the workflow and other inevitable changes to the process have been resolved, it would be appropriate to consider developing a more sophisticated automated version. The cost of extra administrative assistance during the manual phase will be more than offset by the savings in software development costs and speed of completion.

Conclusion

Before trying to automate a business process within a law firm, the process should be developed through manual means or using common electronic tools that do not require programming skills, such as Word documents, Excel spreadsheets and e‑mail. This avoids imposing a culture change on resistant lawyers as part of introducing the automated system and greatly improves the efficiency of developing the automated system itself. The automation project should follow a disciplined approach that employs written business requirements, scope and budget monitoring and reporting to senior people.

[Photo credits: © Can Stock Photo Inc. / novelo & kirstypargeter]