EDRM Critique : From Hand-off to Collaborative Culture

This is the beginning of, and an index to, a series of public critiques of the Socha Gelbman The Electronic Discovery Reference Model (EDRM).

While it takes a bit of negative energy to describe what is wrong with the EDRM, from an Agilist’s perspective, the entire purpose is constructive, so bear with me. This is an evolving critique and I look forward to your constructive comments and input! Trackbacks may work best for now.

Eventually, this series will evolve into a specific constructive model of how E-Discovery might work better, but for now, I’d like to identify problematic issues with the Socha-Gelbman model. Some of these points have probably already be raised elsewhere, and when I find links, I will update this post.

Basically, I believe that lawyers would do well to watch and learn from others who sell their time in exchange for artifacts: software engineers. In the software world, the growing standard measureof accomplishment is not how much we billed, but “does it work”?

I’m not talking about mimicking 20-year old whiz kids,- I’m talking about learning from the people who have taught them how to problem-solve rapidly, flexibly and fearlessly. Not one of the founders of the Agile Manifesto is under 40, and nearly all are still alive, kicking and collaborating to help others get stuff done.

So, with that, here is the start of the discussion:

I. Lawyer as Maestro

Responsibility for the outcome of litigation begins and ends in the client’s office. They pay regardless of who wins. I truly believe (as a mediator and arbitrator) that a majority of client complaints about mediation and arbitration will be greatly alleviated when clients are empowered throughout the process, not just when they make spotlit opening statements.

I’m not an expert on game theory, but I think that has a lot to do with the myth that modern mediation empowers clients.With Agile, there is no confusion.

“Agile” describes a diverse set of processes, practice and principles that are fully and inextricably aligned with the idea that the informed client is the best client, and the lawyers role is best performed as a servant-leader, –not prima donna or maestro.

The EDRM does not explicitly reject the notion of client empowerment, but creates a confusing platform biased in favor of the tasks performed by lawyers and vendors, rather than the needs of clients and court efficiency in managing their disputes.

II. Hand-off Culture

My second observation is that the EDRM is highly structured around the concept of handing off tasks, rather than collaboration.

While risk management is vital, the primary driver of risk management must not be malpractice insurance rates. How can a system devised to compartmentalize lawyer risk operate in the best interest of our clients? It is highly inefficient and favors the risk adverse over the provision of high quality legal services.

The EDRM attempts to build collaboration is into the diagram through a series of arrows, but these really describe shifts in responsibility more than pathways to true collaboration around task completion.

Agile processes begin with the foundational belief that smart people working together can achieve great results efficiently and effectively.

The client may not get to interfere with the team in practices such as Scrum, but scrum team effort is entirely focused on getting the client’s prioritized needs met. I will discuss this in depth with my presentation on Scrum in Litigation in Munich next month.

III. Lawyer as Untrained Project Manager

Courts are beginning to recognize that lawyers are not trained to be good project managers and that they cannot be made so by fiat.

The fact is that even the top law schools do almost nothing to prepare lawyers to manage others well. Further, American litigation culture incentivizes bad behavior much more easily than client-centered collaboration.

As a result, “done” (and Agile buzzword) has been codified in the FRCP as “good enough” from the perspective of lawyer malpractice, when what clients really want and need is “excellence.”

One need only read the Altman-Weil 2009 survey for this to become crystal clear (pun intended). The bottom line is that client satisfaction is not optional.

Not all lawyers are really social engineers, eager to solve problems efficiently, effectively and with client satisfaction at the front of their thinking. Agile is for those who are.

The Project Management Institute seems to have fallen in love (lust?) with Agile, so lawyers who go there might be surprised that they have the options.

Agile is not the be all and end all of project management, but it’s damn good for people who truly love to solve problems.

IV. The Debate Isn’t Whether to Re-Engineer Litigation Processes, It’s How

We can debate how difficult the EDRM is to implement. I would argue that most firms aren’t doing a good job, because 1) they don’t understand it and 2) it’s simply too difficult to implement well.

Maybe we should break it down, but I think it should be scrapped in favor of Agile processes which focus on getting work “Done done,” and working in a collaborative fashion from client to court.

The FRCP firmly supports “lawyer as maestro” thinking, and it is true that in many cases “the buck” must stop with the lawyer who signs a court document. However, it also supports flexibility in process, and this is where Agile principles, practices and processes (3P) have a great deal to offer.

Adopting Agile 3Ps is not a take it or leave it affair, but I believe that once lawyers and their clients get the hang of truly collaborative workflows, they will settle for nothing less!

I look forward to profiling people are are doing this (I know of a few already) to helping your firm or company understand the whys, hows and when’s of Agile adoption.

Please also consider working with me at the Agile Lawyers Association! Our objective to to gather the best thinking on how to improve the practice of law using Agile and we’re devoted to raising the bar, iteratively!

Share and Enjoy:
  • Print
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Blogplay
This entry was posted in Agile 5Ps, Dialexica, EDRM critique, Guiding Light, Transition to Agile and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.