Legal Project Management (Part 10): Where to begin

Which should come first: a formal legal project management system or legal project management training?

This particular chicken and egg question has come up quite a few times in the last few weeks.  For example, I recently talked to a law firm IT project manager who was stunned at how rapidly his fortunes had changed.  He has worked for a firm with over 500 lawyers for several years, and has spent much of that time trying to get lawyers to accept the idea of applying project management principles to legal matters. 

Until a few months ago, nobody listened.  Then the news came out that Dechert had trained every one of its partners in this area and all of a sudden people were asking him to recommend project management systems, tools and training.

Which is where the chicken and egg question comes in.  Does a firm need to have project management software and systems in place before they train lawyers how to work more efficiently?  Or should they begin project management training as quickly as possible, to encourage lawyers to change behavior that can have an immediate impact on client communication and the bottom line? 

If you’ve seen my white paper on Trends in Legal Project Management, you know that I believe that firms should start just in time, just enough training as soon as possible by offering it to motivated influential partners.  The results of these initial sessions will help law firms gain traction in this difficult transition.  The workshops will also pay for themselves by improving the profitability for alternative fee arrangements and by increasing client satisfaction and new business for both hourly and non-hourly work. 

Designing new systems and selecting and installing new software takes time.  While you are creating the perfect customized system, competitors will be racing ahead and stealing your clients. 

This rapid action philosophy reflects an entrepreneurial approach that, in response to global competition, has become increasingly common in companies of all sizes.

For example, many software developers now use “Agile methods,” in which they develop programs as quickly as possible, try them out on users, make changes based on feedback, and try them out again. Rather than spending time on the perfect requirements document, they simply develop release after release until they have a product that truly meets user needs.  As Wikipedia summed it up,

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

The approach is described in the Agile manifesto, which was written by a group of influential software developers in 2001:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

My company has spent many years applying this philosophy to training development.  Before we started working with lawyers and renamed the company LegalBizDev, we spent 20 years developing large training programs for financial services firms and federal agencies. 

When we started out, our government clients required us to follow a formal training development process which demanded that multiple drafts of training materials be reviewed repeatedly by a group of subject matter experts, before they were tried out with a live audience of typical students.

That process produced effective training programs, but they took a very long time to develop.  In some cases, we developed training modules that were absolutely perfect from the subject matter expert’s point of view, only to find that students did not benefit from them.  Those modules were dropped from the course, and all that development time and money was wasted.

After a few years, we began using a leaner process to get in front of students more quickly, by quickly developing “pilot test” materials and getting user feedback.  This approach was faster, cheaper, and ultimately more effective.  That’s one of the elements of the just in time, just enough training approach that we now recommend for legal project management.

Don’t start by rolling out a program for every lawyer in the firm.  Identify small groups of willing and motivated partners, and quickly offer them something that meets their immediate needs.  The training will not be 100% perfect, but it will work well enough to pay for itself several times over.  And success will create a new group of evangelists within the firm who will spread the word: legal project management can help serve clients better. 

While some law firms are taking this “just in time, just enough” approach, others are responding to today’s challenge in a different way: they are forming committees.  On the plus side, committees can build the type of consensus which is needed to make progress in many law firms.  On the minus side, committees almost always slow things down, and this is a moment when law firms need to speed up. 

When I swapped some emails about this problem with Toby Brown of Fulbright & Jaworski (and of Three Geeks and a Law Blog), he noted that,

It's classic for a firm to ‘build then do’ with software and other systems.  A committee attempts to anticipate every need a proposed system might meet before it is developed and rolled-out.  The thinking has been that more input is better, and the process will insure that new systems meet the needs of all the lawyers in the firm.  In my opinion, this has never worked.  Design by committee is a recipe for failure.  Instead of a focused, functional system, you end up with a bloated one that doesn't address the original need….Until you start doing legal project management, you are not going to know your software and system needs.  Buying and implementing software and establishing policies and processes before you know what you need doesn't make sense.  Cart – get thee behind the horse!

I recently had a chance to talk to Eric Elfman, co-founder of a company named Onit which has created a web-based program for legal project management using the Agile approach.  I’ll write about the software in a future post.  (If you can’t wait, you can try the software for free by signing up to be a beta test user.)  During the demo, we talked about my belief that most lawyers need to work on other things – like client communication – before they spend time with software.

Near the end of our conversation, Eric asked, “Do you think lawyers can implement project management without systems and tools?”

“In the long run, absolutely not,” I said.  “But in the short run, they must.”

Why?  Because clients want law firms to increase efficiency and communication NOW.