Author: Onit

Not really. But the process that the legal industry is going through to define legal project management is exactly like the process the industry went through to come up with standards for electronic invoicing in 1997 and 1998, which yielded the Legal Electronic Data Exchange Standards, or LEDES for short.

In the mid-1990’s, companies like AIG, GM, DuPont and countless others were creating their own formats for law firms to submit their invoices electronically. It made sense because there were no standards. Then electronic invoicing vendors like Examen and TyMetrix started writing their own formats and proposing that companies adopt them so that there would be less formats in the market. The short term result was more formats.

The solution was to have the industry get together and agree on a unified standard that may not necessarily cover everyone’s complete wish list, but was enough for law firms, corporations and vendors to start communicating in a common language. Until that happened in 1998, electronic invoicing was only a trickle. After that, the flow of data became a flood.

Today, there is a lot of chatter about legal project management. There are lot of ideas about what it means and why the legal industry needs it. There are also a growing number of definitions of legal project management. I find that they are predominantly from the law firm perspective, though. Not wrong, but our perspective is very much from the buyer of legal services perspective, not the seller. In my view, until the industry finds a way to come together and agree on a definition, legal project management will make little headway.

How the industry gets together to do this is a bit more challenging. In the earlier example of electronic invoicing, PriceWaterhouseCoopers funded the initiative and really facilitated the outcome. They did this, presumably, because they wanted to be seen as thought leaders and to generate fees eventually based on the implementation of electronic invoicing and spend management. And I think they were successful. Who will step forth for legal project management is less obvious. It can’t really be a vendor like Onit. And it can’t really be a law firm. And it can’t really be a corporation. I think it will take a forward-thinking, thought-leading consultancy that understands that investment is necessary here and that it will yield benefits in the future. Any takers?

Finally, in the interest of moving the ball forward, here is my top-level take on what legal project management means for corporate legal departments. Feel free to comment.

1. Initiation
   1. Create project
   1. Define issue
   1. Define project goals and scope of work to be performed
   1. Define desired outcome
   1. Have initial conversation with outside counsel (if necessary) about the project

1. Planning
   1. Agree on a project plan, which breaks all deliverables into discrete items
   1. Agree on a budget according to the project plan
   1. Agree on a staffing plan and detail who will work on the project and at what rate

1. Execution & Monitoring
   1. Begin execution of the project plan
   1. Get weekly status updates (or more frequent for shorter projects)

1. Completion & Evaluation
   1. When a project is complete, go through an evaluation process that includes the following:
   1. 1. Project evaluation
      1. Firm evaluation
      1. Lessons learned
   1. Use closing process to help you create better templates for future projects

As we prepare for our new website launch and begin work on our premium product tailored at the legal vertical, we continue to struggle with how we talk about what we do. Although we designed Onit specifically for lawyers, we quickly realized that Onit is a universal project management tool that any professional, or non-professional for that matter, could use.

At the highest level, a lawyer’s project management needs are not that dissimilar than most people’s needs. On the one hand, we have a great, general project management tool that we will continue to grow for all professionals. On the other hand, our business plan predicts that 100% of our revenue will come from the legal vertical in the next five years.

It is the classic “depth verse breadth” battle that most software companies encounter. So far, we have tried to straddle both: Onit is for everybody; Onit Premium will be for lawyers and people that work with lawyers. Now, we have to find a middle ground that clearly articulates Onit’s value proposition to both audiences.

In our last post we briefly mention waterfall development and why in client work, it’s important to avoid that method when managing a project. To explain why, we want to go into a little more detail on what waterfall development really means.

It is typically defined by seven linear stages: conception, initiation, analysis, design, construction, testing and maintenance. Some of these stages can last months and are usually marked by big milestones. It is only upon the completion of these milestones that the customer or client is reengaged for review.

The advantage of this method is that the customer has to really think about what he wants before software engineers spend time coding. And it allows for predictable, top-down management of engineers from the project manager’s perspective. But the biggest disadvantage of this method is that if the product starts to veer, or if too many project interpretations are wrong, it is a long time before the customer knows it. There is the potential for vast amounts of rework and very unhappy customers.

In the software engineering world, they use a disciplined project management process called “agile” The agile method is based on teamwork, frequent inspection and adaption, self-organization and accountability, and a business approach that aligns work with customer needs and company goals.

We think those tenets should be applied to all project management systems, not just the development world, so the agile method was central to our thinking when we designed Onit.

Agile project management, unlike more traditional systems, is neither linear nor marked by complete specifications being written up front. Agile project managers work in much smaller chunks of time, 2 weeks for example, and fast iteration is key. Yes, specifications still need to be well understood but that doesn’t have to happen up front. Since you are moving fast, you can change those quickly and incorporate new ones as needed. These constant updates also keep everyone in the loop and save time.

We think agile lawyering makes sense. My lawyers and I should iterate more frequently on my projects. Onit allows you to define your goals clearly and up front and then through “discussions” in the service, you can iterate to make sure the project gets completed with the least rework. And you have a running transcript of decisions and conversations. Imagine having one place where you can see everyone’s updates, rather than having to call a meeting to discuss them!