Category: Business Process Management

At Onit, we had to make a decision between using a tag or folder metaphor for “filing” information. We chose tags, and I will tell you why after a short introduction of both possibilities.

You know what folders are if you use a computer. Folders are directories that can contain other folders or files. They are very flexible in that you can create an unlimited number of folders and nested folders to organize your information. The key limitation of most foldering systems is that an item (document, image, file, etc.) can only exist in one folder or sub-folder at a time. Creating your system is complicated up front if you want a logical way to find your information. Not thinking it through up front will typically lead you to a disorganized, “let me just create a new folder for that” approach that is little better than having all of your information in one folder.

Tags are different from the ground up. Unlike folders, where items belong to a folder, a tag belongs to the item. This is an important distinction and one that gives tagging a great advantage over folders. Tagging lets you assign an unlimited number of tags to any item.

If you use any type of photo catalog software, you are probably familiar with tags. For instance, one photo could have a picture of mom (tag “mom”), dad (tag “dad”), Suzy (tag “suzy” and “kids”), Billy (tag “billy” and “kids”) and be from a recent vacation (tag “vacation” and “2010”) in Rome (tag “Europe” and “Italy” and “Rome”). You can see the beauty of this method. With just a couple of clicks, you can now pull out all of the photos with Suzy in them that were taken in Italy in 2010. It is not important what folder these pictures reside in.

I believe that files can benefit similarly from tags. It is rare that a file, let’s say a PowerPoint presentation on the 2010 Marketing Budget, couldn’t also benefit from multiple tags. Say you want to file that presentation. You will probably do something like file it into Marketing or Budget but if you used tags, you could tag it with “presentation” and “2010” and “marketing” and “budget.” That would give you a much richer way to find relevant information.

The downside of tags, though, is that you typically don’t see your information in the same hierarchical way that folders allow. But does that really matter in this search-centric world? I don’t folder much of anything anymore; I simply search. But tags make search much more valuable. And, if you really need it, there are ways to make tags look like folders.

Here at Onit, we chose tags as the metaphor for adding meta data to documents and projects. We think it works. Let us know what you think.

I had some preconceived notions about budgeting for legal projects going into the design phase for the Onit legal budgeting set of features.

First, I believed that our primary market, corporate legal departments with $1 to $6 billion in revenue, would want their law firms to create and submit a budget. After all, that is what the Fortune 500 market wants. Second, I believed that our primary market would want detailed budgets, at least at the phase level. After all, Fortune 500 corporate legal departments want to budget at even a greater level of detail. Both of these preconceived notions were wrong. And not just a little, but 100% wrong.

For a market that does very little budgeting today, a little bit of functionality goes a long way. As a result, we will deliver life of project and annual budgeting capabilities and skip the detail for now. Budgets, while they can be informed by law firm input, will really be created by the corporation. It is clear the general counsel in these companies rely much more on the expertise and opinion of their own employees about project costs than they do their vendors.

We have learned a couple of other things that would be more helpful than more detail. In addition to providing budget to actual comparisons, we will also be trying to extract some meta data about the invoice and the project at the time of invoice submission by the law firm and invoice approval by the inside project owner. Specifically, knowing what your spend is compared to your budget is not that meaningful unless you also know where your project is compared to its estimated completion. For instance, knowing that you are at 50% in a project is enhanced by the knowledge that you are 67% through with the legal work on the project. Your budget to actual comparison is now informed in a very meaningful way.

So in addition to collecting an invoice, we will also want to know whether there is a new estimate for project completion costs or date. These are relatively simple things to collect in our model with value that far exceeds the cost to collect.

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!